Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a...

41
Private Public Partnership Project (PPP) Large-scale Integrated Project (IP) D.14 .7.2: FIWARE Technical Roadmap (IoT Chapter) Project acronym: FI-Core Project full title: Future Internet Core Contract No.: 632893 Strategic Objective: FI.ICT-2011.1.7 Technology foundation: Future Internet Core Platform Project Document Number: ICT-2013-FI-632893-1 4 -D.14.7.2 Project Document Date: 29.04.2016 Deliverable Type and Security: Public Authors: Gilles Privat (Orange), Carlos Ralli Ucendo (TID) Contributors: all chapter members

Transcript of Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a...

Page 1: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Private Public Partnership Project (PPP)

Large-scale Integrated Project (IP)

D14 72 FIWARE Technical Roadmap (IoT Chapter)

Project acronym FI-Core

Project full title Future Internet Core

Contract No 632893

Strategic Objective FIICT-201117 Technology foundation Future Internet Core Platform

Project Document Number ICT-2013-FI-632893-1 4 -D1472

Project Document Date 29042016

Deliverable Type and Security Public

Authors Gilles Privat (Orange) Carlos Ralli Ucendo (TID)

Contributors all chapter members

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 2

1 Introduction

11 Executive Summary

This document describes the roadmap of the features that FIWARE IoT chapter will deliver in the future

giving a detailed account of the schedule for the minor releases of Release 5

A clear table shows the releases amp sprints mapping them to calendar dates in the whole history of the

platform until the end of Release 5 (September 2016) This technical chapter provides its internal

roadmap for Release 5 in relation with this table

The present document is a periodic issue that contains a snapshot of the state of the roadmap of the IoT

chapter The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep

it up to date accurately showing the results that will deliver in coming releases

12 About This Document

Internet of Things chapter provides the Generic Enablers to allow Things to become available

searchable accessible and usable context resources fostering FIWARE-based Apps interaction with real-

life objects

In this context Things mean any physical object living organism person or concept interesting from the

perspective of an application and whose parameters are totally or partially tied to sensors actuators or

combinations of them

13 Intended Audience

The document targets those interested in the intended direction of FIWAREs IoT Chapter

14 Structure of this Document

The document is generated out of a set of documents provided in the public FIWARE wiki For the

current version of the documents please visit the public wiki at httpwikifiwareorg

The following resources were used to generate this document

httpwikifiwareorgFIWARE_Techical_Roadmap

httpwikifiwareorgReleases and Sprints numbering with mapping to calendar dates

httpwikifiwareorgRoadmap_of_Internet_of_Things_(IoT)_Services

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 3

Backend Device Management GE

bull httpwikifiwareorgFIWAREEpicIoTIDASModularity

bull httpwikifiwareorgFIWAREEpicIoTIDASProtocols

bull httpwikifiwareorgFIWAREEpicIoTIDASDevKit

bull httpwikifiwareorgFIWAREEpicIoTIDASGeoDescription

bull httpwikifiwareorgFIWAREEpicIoTIDASEdgeManagement

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityHomogeneousCommands

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityDevicesTimezone

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityDeviceLifeCicle

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityDeleteFunctions

bull httpwikifiwareorgFIWAREFeatureIoTIDASProtocolsOneM2MBasic

bull httpwikifiwareorgFIWAREFeatureIoTIDASDevKitSDKIntelEdison

bull httpwikifiwareorgFIWAREFeatureIoTIDASDevKitSDKArduino

bull httpwikifiwareorgFIWAREFeatureIoTIDASProtocolsnodejsMigration

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityNewGithubOrganization

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityImproveOperations

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityIoTManagerAdvanced

bull httpwikifiwareorgFIWAREFeatureIoTIDASEdgeManagementIoTInfrastructure

bull httpwikifiwareorgFIWAREFeatureIoTIDASGeoDescriptionPOIs-Integration

IoT Broker GE

bull httpwikifiwareorgFIWAREFeatureIoTBackendIoTBrokerSmartUpdateHandler

bull httpwikifiwareorgFIWAREFeatureIoTBackendIoTBrokerHistoryQueries

bull httpwikifiwareorgFIWAREFeatureIoTBackendIoTBrokerAdvancedQueries

bull httpwikifiwareorgFIWAREFeatureIoTBackendIoTBrokerInterfaceNGSIv2

IoT Discovery GE

bull httpwikifiwareorgFIWAREEpicIoTIoTDiscoveryInterface

bull httpwikifiwareorgFIWAREEpicIoTIoTDiscoveryInteroperability

bull httpwikifiwareorgFIWAREEpicIoTIoTDiscoveryRepository

bull httpwikifiwareorgFIWAREFeatureIoTIoTDiscoveryRepositoryDatasetGenerator

bull httpwikifiwareorgFIWAREFeatureIoTIoTDiscoveryInterfaceSemanticRegApiV2

bull httpwikifiwareorgFIWAREFeatureIoTIoTDiscoveryInterfaceNgsiV2

bull httpwikifiwareorgFIWAREFeatureIoTIoTDiscoveryRepositoryNgsi9OnDocumentS

tore

bull httpwikifiwareorgFIWAREFeatureIoTIoTDiscoveryInterfaceWebUI

bull IoT Data Edge Consolidation GE

bull httpwikifiwareorgFIWAREEpicIoTIotDataEdgeConsolidationLocalStorage

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusBroker

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 4

bull httpwikifiwareorgFIWAREEpicIoTIotDataEdgeConsolidationCommonDataModel

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusCEP

bull httpwikifiwareorgFIWAREEpicIoTIotDataEdgeConsolidationManager

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusNGSIv2

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusNGSIv1

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusNGSI9

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusGUI

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusBrokerPersistentPubSub

bull httpwikifiwareorgFIWAREFeatureIoTIotDataEdgeConsolidationCommonDataMod

elNGSIV2GeolocTimestamp

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-

CepheusBrokerRemoteBrokerFilter

bull httpwikifiwareorgFIWAREFeatureIoTIotDataEdgeConsolidationComplexEventPro

cessingComplexType

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusCEPMultiTenant

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusGUICepConfiguration

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusNGSIv2Basic

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusNGSIv1REST

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusCEPAPIMonitoring

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusNGSI9Operations

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusCEPNGSIConfiguration

The present document has been created from the wiki using automated tools and part of the links may

not work You may occasionally find oddities in the text format that side effects of the process but they

do not deter the quality of the technical contents

15 Keyword list

FIWARE FI-Core Acceleration Programme Accelerators PPP Architecture Board Steering Board

Roadmap Reference Architecture Generic Enabler Open Specifications I2ND Cloud IoT DataMedia

and Context Management ApplicationsServices and Data Delivery Delivery Framework Security

Advanced Middleware Interfaces to Networks and Robotics Communities Tools Sustainability Support

Tools ICT esInternet Apiary Github Latin American Platform

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 5

16 Changes History

Release Major changes description Date Editor

v1 Version for delivery 2015-01-18 Gilles Privat

17 Table of Contents

1 Introduction 2

11 Executive Summary 2

12 About This Document 2

13 Intended Audience 2

14 Structure of this Document 2

15 Keyword list 4

16 Changes History 5

17 Table of Contents 5

2 FIWARE Technical Roadmap 8

3 Releases and Sprints numbering with mapping to calendar dates 10

4 Roadmap of Internet of Things (IoT) Services 11

41 Introduction 11

42 Fifth Major Release 11

421 Backend 11

422 Gateway 14

43 Future releases 15

5 Backend Device Management GE 17

51 IDAS Modularity Epic 17

52 IDAS Protocols Epic 17

53 IDAS DevKit Epic 18

54 IDAS GeoDescription Epic 18

55 IDAS EdgeManagement Epic 19

56 Modularity ndash Homogeneous Commands Feature 19

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 6

57 Modularity ndash Devices Timezone Feature 20

58 Modularity ndash Device Life Cicle Feature 20

59 Modularity ndash Delete Functions Feature 21

510 Protocols - OneM2M Basic Feature 21

511 DevKit ndash SDK Intel Edison Feature 22

512 DevKit ndash SDK Arduino Feature 22

513 Protocols ndash nodejs Migration Feature 22

514 Modularity ndash New Github Organization Feature 23

515 Modularity ndash Improve Operations Feature 23

516 Modularity ndash IoT Manager Advanced Feature 24

517 EdgeManagement ndash IoT Infrastructure Feature 24

518 GeoDescription POIs Integration Feature 25

6 Backend IoT Broker GE 26

61 Smart Update Handler Feature 26

62 History Queries Feature 26

63 Advanced Queries Feature 27

64 Interface NGSIv2 Feature 27

7 Backend IoT Discovery GE 28

71 Interface Epic 28

72 Interoperability Epic 28

73 Repository Epic 29

74 Repository - NGSI9 GeoLocation Feature 29

75 Repository ndash Dataset Generator Feature 30

76 Interface ndash Semantic RegApiv2 Feature 30

77 Interface - NGSIv2 Feature 31

78 Repository - NGSI9 On-Document Store Feature 31

8 IoT Data Edge Consolidation GE 32

81 Local Storage Epic 32

82 DataEdge Cepheus Broker Epic 32

83 Common Data Model Epic 33

84 DataEdge Cepheus CEP Epic 33

85 Manager Epic 33

86 DataEdge Cepheus NGSIv2 Epic 34

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 7

87 DataEdge Cepheus NGSIv1Epic 34

88 DataEdge Cepheus NGSI9 Epic 35

89 DataEdge Cepheus GUI Epic 35

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature 36

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature 36

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature 37

813 Complex Event Processing ndash Complex Type Feature 37

814 Data Edge Cepheus CEP ndash MultiTenant Feature 37

815 Data Edge Cepheus GUI ndash Cep Configuration Feature 38

816 Data Edge Cepheus - NGSIv2 Basic Feature 39

817 Data Edge Cepheus NGSIv1 REST Feature 39

818 Data Edge Cepheus CEP ndash API Monitoring Feature 40

819 Data Edge Cepheus NGSI9 - Operations Feature 40

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature 41

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 8

2 FIWARE Technical Roadmap

FIWAREs technical roadmap brings information about what the different major releases of FIWARE will

bring and when they will be available on FIWARE Lab For each of the FIWARE chapters and for every

generic enabler the list of features available for the particular release is linked within the following

pages You can explore which release number the particular features are currently scheduled for and

contact the affiliated responsible persons in charge if you need more details

The first version of the FIWARE platform was made available on the FIWARE Testbed during 3Q2012 for

experiments by the use case projects within the FI-PPP program The overall goal for this first Release

was to provide a sufficiently complete set of FIWARE GEs which Use Case Projects selected in the first

phase of the FI-PPP program could test and use in their proof of concepts The second release of FIWARE

is focused on integration (both inside and across chapters) as well as evolution of FIWARE GEs based on

feedback from target Users (both Use Case Projects selected in the first phase of the FI-PPP or other

stakeholders like currenttarget customers of FIWARE partners) The third release is focused on

consolidation of the platform and packaging

The fourth and fifth releases will be delivered by a new set of partners (many of them already present in

releases 1 2 and 3) and will bring a reorganization of the map of GEs These GEs will continue building

the core platform ensuring that the results are open and royalty free

Once the development of a given minor release of FIWARE is finished it can be made available on

FIWARE Lab typically by the end of the following month Updates of all FIWARE GEs on FIWARE Lab will

be planned after each major release completion Nevertheless updates of FIWARE Lab may be decided

on a more frequent basis at FIWARE GE level ie the following month after completion of some Sprint

Please check the Releases and Sprints numbering with mapping to calendar dates for further

information

FIWAREs Technical Roadmap is broken into 7 partial roadmaps one per FIWARE Technical Chapter

Roadmap of Cloud Hosting

Roadmap of DataContext Management

Roadmap of Internet of Things (IoT) Services

Roadmap of ApplicationsServices Ecosystem and Delivery Framework

Roadmap of Security

Roadmap of Advanced middleware Interface to Networks and Robotics

Roadmap of Advanced Web-based UI

The Developers Community and Tools chapter has changed their focus and they do not produce GEs as

such anymore We keep their past roadmap as it was at the end of 2014 for future reference

Roadmap of Developers Community and Tools

Important Note it is important to mention that most (if not all) of the Generic Enabler implementations

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 9

are based on existing baseline assets (open source or proprietary) actively developed and promoted by

the corresponding companies Each company has done internal analysis of requirements and priorities

for each of the technologies based on their business needs and the needs of their customers The goal

of FIWARE is to develop these assets even further to integrate them together to form a coherent

platform and to offer them to the FI-PPP ecosystem for the benefit of the community This roadmap

reflects this approach

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 10

3 Releases and Sprints numbering with mapping to

calendar dates The list of Releases and Sprints together with the time frame of each one of them is depicted in the

following table

Versions

Oct

201

4

No

v

201

4

De

c

201

4

Jan

201

5

Feb

201

5

Ma

r

201

5

Apr

201

5

Ma

y

201

5

Jun

201

5

Jul

201

5

Au

g

201

5

Sep

201

5

Oct

201

5

No

v

201

5

De

c

201

5

Jan

201

6

Feb

201

6

Ma

r

201

6

Apr

201

6

Ma

y

201

6

Jun

201

6

Jul

201

6

Au

g

201

6

Sep

201

6

FIWARE(Clo

sed) Month

Number

M4

2

M4

3

M4

4

FIWARE

Continuatio

n (ongoing)

Month

Number

M2 M3 M4 M5 M6 M7 M8 M9 M1

0

M1

1

M1

2

M1

3

M1

4

M1

5

M1

6

M1

7

M1

8

M1

9

M2

0

M2

1

M2

2

M2

3

M2

4

M2

5

First Major

Release

Second

Major

Release

Third Major

Release

Fourth

Major

Release

41

1

41

2

41

3

42

1

42

2

42

3

43

1

43

2

43

3

44

1

44

2

44

3

Fifth Major

Release

51

1

51

2

51

3

52

1

52

2

52

3

53

1

53

2

53

3

54

1

54

2

54

3

PLEASE NOTE that software associated to Minor Releases may be made available on the FIWARE

Testbed and FIWARE Lab after completing that Minor Release typically by the end of the following

month A revised version of the documentation accompanying software delivered after closing a Minor

Release is also typically delivered by end of the following month

Updates of all FIWARE GEs on the FIWARE Testbed will be planned after each Major Release completion

Besides updates of the FIWARE Testbed may be decided on a more frequent basis at FIWARE GE level

ie the following month after completion of some Sprint

As explained in FIWARE Agile Development Methodology the Releases and Sprints are referred to as

FIWAREReleasexy

FIWARESprintxyz

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 11

4 Roadmap of Internet of Things (IoT) Services

41 Introduction

The Internet of Things Service Enablement chapter in FIWARE provides key assets enabling access to IoT

resources

You can learn more about the IoT Chapter by reading the FIWARE Architecture and Open Specifications

Following is a description of the Technical Roadmap planned for the chapter which will be developed

through subsequent Releases of the FIWARE Platform Please also check the Releases and Sprints

numbering with mapping to calendar dates

42 Fifth Major Release

Following is a description of features per Generic Enablers that will be supported in Release 5 of

FIWARE both in the backend and gateway parts

421 Backend

4211 Backend Device Management

o Addition of new IoT protocols by means of new dedicated IoT Agents Examples

OneM2M (inlcuding MCA northbound interface) amp Modbus

o Development of IoT Agents at the Gateway level Mainly to replace the previous

Protocol Adapater GE

o Deliver new SDKs for different hardware platforms Arduino Cludino Intel Edision

ThinkingThings Open RaspberryPI etc

o Enable new features such as Device Management IoT infrastructure management

(using NGSI entities) etc

o Migration of all IoT Agents to nodejs implementations

4212 Backend IoT Broker

o intelligent update request handling

o efficient and energy saving IoT subsystem invocation

o Enhance interface capabilities

o harmonize additional interface features towards NGSI v2 support

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 12

4213 Backend IoT Discovery

o Support geo-location discovery of entities

o evolve (semantic) linked-data platform API to 2nd version

o evolve NGSI API to 2nd version

o provide ontology for IoT entities

o provide a dataset generator for initial testing

o change store from object database to document store

FIWARE

GE Supported Features Epics under analysis

Backend

Device

Manage

ment

Release 51

FIWAREFeatureIoTIDASModularityHomog

eneousCommands

FIWAREFeatureIoTIDASModularityDevices

Timezone

FIWAREFeatureIoTIDASModularityDeviceL

ifeCicle

FIWAREFeatureIoTIDASModularityDeleteF

unctions

Release 52

FIWAREFeatureIoTIDASProtocolsOneM2M

Basic

FIWAREFeatureIoTIDASDevKitSDKIntelEdis

on

FIWAREFeatureIoTIDASDevKitSDKArduino

Release 53

FIWAREFeatureIoTIDASProtocolsnodejsMi

gration

FIWAREFeatureIoTIDASModularityNewGit

hubOrganization

FIWAREFeatureIoTIDASModularityImprov

eOperations

FIWAREEpicIoTIDASModula

rity

FIWAREEpicIoTIDASProtoc

ols

FIWAREEpicIoTIDASDevKit

FIWAREEpicIoTIDASGeoDes

cription

FIWAREEpicIoTIDASEdgeM

anagement

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 13

Release 54

FIWAREFeatureIoTIDASModularityIoTMan

agerAdvanced

FIWAREFeatureIoTIDASEdgeManagementI

oTInfrastructure

FIWAREFeatureIoTIDASGeoDescriptionPOI

s-Integration

Backend

IoT

Broker

Release 51

FIWAREFeatureIoTBackendIoTBrokerSmart

UpdateHandler

Release 52

FIWAREFeatureIoTBackendIoTBrokerHistor

yQueries

FIWAREFeatureIoTBackendIoTBrokerAdva

ncedQueries

Release 53

FIWAREFeatureIoTBackendIoTBrokerInterf

aceNGSIv2

Release 54

IoT

Discover

y

Release 51

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9GeoLocation

FIWAREFeatureIoTIoTDiscoveryInterfaceS

emanticRegApiV2

FIWAREFeatureIoTIoTDiscoveryRepository

DatasetGenerator

Release 52

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

FIWAREFeatureIoTIoTDiscoveryInterfaceN

FIWAREEpicIoTIoTDiscovery

Interface

FIWAREEpicIoTIoTDiscovery

Interoperability

FIWAREEpicIoTIoTDiscovery

Repository

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 14

gsiV2

Release 53

FIWAREFeatureIoTIoTDiscoveryInterfaceN

gsiV2

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

Release 54

FIWAREFeatureIoTIoTDiscoveryInterface

WebUI

422 Gateway

4221 IoT Data Edge Consolidation

The main effort in release 5 is to be compliant NGSI V2 and to improve the robustness of the broker and

the CEP

o the CEP will offer geofencing operations

o the broker will be compliant ngsi9

o the broker and the CEP will interface with other GE with NGSI V2

FIWAR

E GE Supported Features Epics under analysis

IoT

Data

Edge

Consol

idatio

Release 51

FIWAREFeatureIoTIotDataEdgeConsolidati

onLocalStoragepubsub

FIWAREEpicIoTIotDataEdgeCo

nsolidationLocalStorage

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 15

n FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2GeolocTimes

tamp

FIWAREFeatureIoTIotDataEdgeConsolidati

onBrokerFilterUpdateContext

FIWAREFeatureIoTIotDataEdgeConsolidati

onComplexEventProcessingComplexType

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSI9

Release 52

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2

Release 53

FIWAREFeatureIoTIotDataEdgeConsolidati

onManagerNgsiConfiguration

Release 54

FIWAREFeatureIoTDataEdge-

CepheusNGSI9Operations

FIWAREFeatureIoTDataEdge-

CepheusCEPNGSIConfiguration

FIWAREEpicIoTIotDataEdgeCo

nsolidationBroker

FIWAREEpicIoTIotDataEdgeCo

nsolidationCommonDataModel

FIWAREEpicIoTIotDataEdgeCo

nsolidationComplexEventProce

ssing

FIWAREEpicIoTIotDataEdgeCo

nsolidationManager

43 Future releases

The following features and epics correspond to features that are in the roadmap of the respective

Generic Enablers but are not going to be implemented as part of FIWARE project activities Some of

them may continue under the FIWARE Community activities some others will not

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 16

You can check out the previous releases of this FIWARE chapter on Roadmap of Internet of Things (IoT)

Services(previous releases)

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 17

5 Backend Device Management GE

51 IDAS Modularity Epic

Name Refactoring

IoT Agents

Chapter IoT

Goal Evolution of the architecture and implementation according to developers

feedback

Description To evolve from a C++ monolithic architecture (extensible via C++ plugins) towards

a modular design where each module (IoT Agent) focusses on a reduce set of IoT

Southbound Protocols and is written in any language This will significantly reduce

the complexity of installation and operation of this component

Rationale Lighter architecture and easier installation operation and extensibility The idea is

to provide modules (IoT Agents) for one or a reduced number of IoT southbound

protocols for easier installation and improved operations and scalability

52 IDAS Protocols Epic

Name New

Protocols

- IoT

Agents

Chapter

IoT

Goal Evolution of the architecture and implementation according to industry trends

Description Besides providing backwards compatibility new southbound technologies and

protocols need to be adopted as long as there are new proposals comming from

Industrial alliances and also open and propietary standards that are relavnt

enough to be adopted

Rationale To make FIWARE IoT competitive regarding the latest emerging trends and

industrial propositions The idea behind the IoT agents is to provide such an easy

extensibility and IoT Agents skeletons are provided to developers (in C++ and

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 18

nodejs) so they can also add new protocols if needed

53 IDAS DevKit Epic

Name FIGWAY

Testing

Tools

Chapter

IoT

Goal Provide a set of testing and training tools regarding FIWARE IoT

Description To provide means for experimenting with different kinds of virtual or pyhical

sensor and actuators Particularly virtual sensors emnable simulations and Apps

developmen t before installing devices in place allowing issues antcipation and

improving time to market of IoT projects

Rationale Easy learning testing and training with FIWARE IoT by providing software tools to

be installed in gateways andor laptops desktop PCs etc to perform simulations

54 IDAS GeoDescription Epic

Name Geographical

Description

Chapter IoT

Goal Identify standard methods to add geolocation data to IoT devices so that graphical

representation can be improved

Description Identify standard methods and protocols to add geolocation data to IoT devices so

that graphical representation can be improved Therea re many available options

but the one that is being worked out in the data chapter for the 2D and 3D

interfaces has been finally selected

Rationale Improve graphical presentation of IoT by providing a standar way to add location

metadata to the devices themselves The specification guarantees the

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 19

compatibility with the FIWARE 2D and 3D user interfaces

55 IDAS EdgeManagement Epic

Name IoT Edge

Management

Chapter IoT

Goal Provide an easy way to configure underlaying southbound infrastructure

(gateways networks connectivity security etc)

Description To make the life of IoT providers easier with platform tools So far IDAS was

mainly focussed on translating southbound IoT protocols intro NGSI but this EPIC

will cover the easy deployment and operations of Edge related elements

(gateways connectivity etc)

Rationale The idea behind this EPIC is to make IoT deployments easier and consider the

feedback provided by developers and integrators on this specific area

56 Modularity ndash Homogeneous Commands Feature

Name BE

DeviceManagement

Homogeneous

Commands

Chapter

IoT

Goal Implement the new specs for commands (real-time andor polling) for all IoT

Agents

Description This feature aligns all IoT Agents regarding commands delivery The idea is to

have a common specification for all the ADMIN API and Commands API of the

different IoT Agents

Rationale Provide a common ADMIN API and Commands API for all IoT Agents The

ADMIN API is a REST HTTP API that is similar to the IoT Manager one and it

enables Admins to provision devices services subservices and other

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 20

configurable elements

57 Modularity ndash Devices Timezone Feature

Name BE

DeviceManagement

Device Timezone

Functions

Chapter

IoT

Goal Implement a Timezone function (devices not in GMT) for all IoT Agents

Description This feature aligns all IoT Agents to be able to configure the timezone of

devices The idea is to have a common specification for all the ADMIN API of

the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST

HTTP API that is similar to the IoT Manager one and it enables Admins to

provision devices services subservices and other configurable elements

58 Modularity ndash Device Life Cicle Feature

Name BE

DeviceManagement

Device Life Cicle

Functions

Chapter

IoT

Goal Implement Device Life Cicle functions (enabledisable in addition to

provisiondelete) for all IoT Agents

Description This feature aligns all IoT Agents to be able to manage devices and other

configurable elements (for instance configure a service to accept only pre-

provisioned devices) The idea is to have a common specification for all the

ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 2: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 2

1 Introduction

11 Executive Summary

This document describes the roadmap of the features that FIWARE IoT chapter will deliver in the future

giving a detailed account of the schedule for the minor releases of Release 5

A clear table shows the releases amp sprints mapping them to calendar dates in the whole history of the

platform until the end of Release 5 (September 2016) This technical chapter provides its internal

roadmap for Release 5 in relation with this table

The present document is a periodic issue that contains a snapshot of the state of the roadmap of the IoT

chapter The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep

it up to date accurately showing the results that will deliver in coming releases

12 About This Document

Internet of Things chapter provides the Generic Enablers to allow Things to become available

searchable accessible and usable context resources fostering FIWARE-based Apps interaction with real-

life objects

In this context Things mean any physical object living organism person or concept interesting from the

perspective of an application and whose parameters are totally or partially tied to sensors actuators or

combinations of them

13 Intended Audience

The document targets those interested in the intended direction of FIWAREs IoT Chapter

14 Structure of this Document

The document is generated out of a set of documents provided in the public FIWARE wiki For the

current version of the documents please visit the public wiki at httpwikifiwareorg

The following resources were used to generate this document

httpwikifiwareorgFIWARE_Techical_Roadmap

httpwikifiwareorgReleases and Sprints numbering with mapping to calendar dates

httpwikifiwareorgRoadmap_of_Internet_of_Things_(IoT)_Services

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 3

Backend Device Management GE

bull httpwikifiwareorgFIWAREEpicIoTIDASModularity

bull httpwikifiwareorgFIWAREEpicIoTIDASProtocols

bull httpwikifiwareorgFIWAREEpicIoTIDASDevKit

bull httpwikifiwareorgFIWAREEpicIoTIDASGeoDescription

bull httpwikifiwareorgFIWAREEpicIoTIDASEdgeManagement

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityHomogeneousCommands

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityDevicesTimezone

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityDeviceLifeCicle

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityDeleteFunctions

bull httpwikifiwareorgFIWAREFeatureIoTIDASProtocolsOneM2MBasic

bull httpwikifiwareorgFIWAREFeatureIoTIDASDevKitSDKIntelEdison

bull httpwikifiwareorgFIWAREFeatureIoTIDASDevKitSDKArduino

bull httpwikifiwareorgFIWAREFeatureIoTIDASProtocolsnodejsMigration

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityNewGithubOrganization

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityImproveOperations

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityIoTManagerAdvanced

bull httpwikifiwareorgFIWAREFeatureIoTIDASEdgeManagementIoTInfrastructure

bull httpwikifiwareorgFIWAREFeatureIoTIDASGeoDescriptionPOIs-Integration

IoT Broker GE

bull httpwikifiwareorgFIWAREFeatureIoTBackendIoTBrokerSmartUpdateHandler

bull httpwikifiwareorgFIWAREFeatureIoTBackendIoTBrokerHistoryQueries

bull httpwikifiwareorgFIWAREFeatureIoTBackendIoTBrokerAdvancedQueries

bull httpwikifiwareorgFIWAREFeatureIoTBackendIoTBrokerInterfaceNGSIv2

IoT Discovery GE

bull httpwikifiwareorgFIWAREEpicIoTIoTDiscoveryInterface

bull httpwikifiwareorgFIWAREEpicIoTIoTDiscoveryInteroperability

bull httpwikifiwareorgFIWAREEpicIoTIoTDiscoveryRepository

bull httpwikifiwareorgFIWAREFeatureIoTIoTDiscoveryRepositoryDatasetGenerator

bull httpwikifiwareorgFIWAREFeatureIoTIoTDiscoveryInterfaceSemanticRegApiV2

bull httpwikifiwareorgFIWAREFeatureIoTIoTDiscoveryInterfaceNgsiV2

bull httpwikifiwareorgFIWAREFeatureIoTIoTDiscoveryRepositoryNgsi9OnDocumentS

tore

bull httpwikifiwareorgFIWAREFeatureIoTIoTDiscoveryInterfaceWebUI

bull IoT Data Edge Consolidation GE

bull httpwikifiwareorgFIWAREEpicIoTIotDataEdgeConsolidationLocalStorage

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusBroker

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 4

bull httpwikifiwareorgFIWAREEpicIoTIotDataEdgeConsolidationCommonDataModel

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusCEP

bull httpwikifiwareorgFIWAREEpicIoTIotDataEdgeConsolidationManager

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusNGSIv2

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusNGSIv1

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusNGSI9

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusGUI

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusBrokerPersistentPubSub

bull httpwikifiwareorgFIWAREFeatureIoTIotDataEdgeConsolidationCommonDataMod

elNGSIV2GeolocTimestamp

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-

CepheusBrokerRemoteBrokerFilter

bull httpwikifiwareorgFIWAREFeatureIoTIotDataEdgeConsolidationComplexEventPro

cessingComplexType

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusCEPMultiTenant

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusGUICepConfiguration

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusNGSIv2Basic

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusNGSIv1REST

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusCEPAPIMonitoring

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusNGSI9Operations

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusCEPNGSIConfiguration

The present document has been created from the wiki using automated tools and part of the links may

not work You may occasionally find oddities in the text format that side effects of the process but they

do not deter the quality of the technical contents

15 Keyword list

FIWARE FI-Core Acceleration Programme Accelerators PPP Architecture Board Steering Board

Roadmap Reference Architecture Generic Enabler Open Specifications I2ND Cloud IoT DataMedia

and Context Management ApplicationsServices and Data Delivery Delivery Framework Security

Advanced Middleware Interfaces to Networks and Robotics Communities Tools Sustainability Support

Tools ICT esInternet Apiary Github Latin American Platform

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 5

16 Changes History

Release Major changes description Date Editor

v1 Version for delivery 2015-01-18 Gilles Privat

17 Table of Contents

1 Introduction 2

11 Executive Summary 2

12 About This Document 2

13 Intended Audience 2

14 Structure of this Document 2

15 Keyword list 4

16 Changes History 5

17 Table of Contents 5

2 FIWARE Technical Roadmap 8

3 Releases and Sprints numbering with mapping to calendar dates 10

4 Roadmap of Internet of Things (IoT) Services 11

41 Introduction 11

42 Fifth Major Release 11

421 Backend 11

422 Gateway 14

43 Future releases 15

5 Backend Device Management GE 17

51 IDAS Modularity Epic 17

52 IDAS Protocols Epic 17

53 IDAS DevKit Epic 18

54 IDAS GeoDescription Epic 18

55 IDAS EdgeManagement Epic 19

56 Modularity ndash Homogeneous Commands Feature 19

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 6

57 Modularity ndash Devices Timezone Feature 20

58 Modularity ndash Device Life Cicle Feature 20

59 Modularity ndash Delete Functions Feature 21

510 Protocols - OneM2M Basic Feature 21

511 DevKit ndash SDK Intel Edison Feature 22

512 DevKit ndash SDK Arduino Feature 22

513 Protocols ndash nodejs Migration Feature 22

514 Modularity ndash New Github Organization Feature 23

515 Modularity ndash Improve Operations Feature 23

516 Modularity ndash IoT Manager Advanced Feature 24

517 EdgeManagement ndash IoT Infrastructure Feature 24

518 GeoDescription POIs Integration Feature 25

6 Backend IoT Broker GE 26

61 Smart Update Handler Feature 26

62 History Queries Feature 26

63 Advanced Queries Feature 27

64 Interface NGSIv2 Feature 27

7 Backend IoT Discovery GE 28

71 Interface Epic 28

72 Interoperability Epic 28

73 Repository Epic 29

74 Repository - NGSI9 GeoLocation Feature 29

75 Repository ndash Dataset Generator Feature 30

76 Interface ndash Semantic RegApiv2 Feature 30

77 Interface - NGSIv2 Feature 31

78 Repository - NGSI9 On-Document Store Feature 31

8 IoT Data Edge Consolidation GE 32

81 Local Storage Epic 32

82 DataEdge Cepheus Broker Epic 32

83 Common Data Model Epic 33

84 DataEdge Cepheus CEP Epic 33

85 Manager Epic 33

86 DataEdge Cepheus NGSIv2 Epic 34

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 7

87 DataEdge Cepheus NGSIv1Epic 34

88 DataEdge Cepheus NGSI9 Epic 35

89 DataEdge Cepheus GUI Epic 35

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature 36

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature 36

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature 37

813 Complex Event Processing ndash Complex Type Feature 37

814 Data Edge Cepheus CEP ndash MultiTenant Feature 37

815 Data Edge Cepheus GUI ndash Cep Configuration Feature 38

816 Data Edge Cepheus - NGSIv2 Basic Feature 39

817 Data Edge Cepheus NGSIv1 REST Feature 39

818 Data Edge Cepheus CEP ndash API Monitoring Feature 40

819 Data Edge Cepheus NGSI9 - Operations Feature 40

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature 41

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 8

2 FIWARE Technical Roadmap

FIWAREs technical roadmap brings information about what the different major releases of FIWARE will

bring and when they will be available on FIWARE Lab For each of the FIWARE chapters and for every

generic enabler the list of features available for the particular release is linked within the following

pages You can explore which release number the particular features are currently scheduled for and

contact the affiliated responsible persons in charge if you need more details

The first version of the FIWARE platform was made available on the FIWARE Testbed during 3Q2012 for

experiments by the use case projects within the FI-PPP program The overall goal for this first Release

was to provide a sufficiently complete set of FIWARE GEs which Use Case Projects selected in the first

phase of the FI-PPP program could test and use in their proof of concepts The second release of FIWARE

is focused on integration (both inside and across chapters) as well as evolution of FIWARE GEs based on

feedback from target Users (both Use Case Projects selected in the first phase of the FI-PPP or other

stakeholders like currenttarget customers of FIWARE partners) The third release is focused on

consolidation of the platform and packaging

The fourth and fifth releases will be delivered by a new set of partners (many of them already present in

releases 1 2 and 3) and will bring a reorganization of the map of GEs These GEs will continue building

the core platform ensuring that the results are open and royalty free

Once the development of a given minor release of FIWARE is finished it can be made available on

FIWARE Lab typically by the end of the following month Updates of all FIWARE GEs on FIWARE Lab will

be planned after each major release completion Nevertheless updates of FIWARE Lab may be decided

on a more frequent basis at FIWARE GE level ie the following month after completion of some Sprint

Please check the Releases and Sprints numbering with mapping to calendar dates for further

information

FIWAREs Technical Roadmap is broken into 7 partial roadmaps one per FIWARE Technical Chapter

Roadmap of Cloud Hosting

Roadmap of DataContext Management

Roadmap of Internet of Things (IoT) Services

Roadmap of ApplicationsServices Ecosystem and Delivery Framework

Roadmap of Security

Roadmap of Advanced middleware Interface to Networks and Robotics

Roadmap of Advanced Web-based UI

The Developers Community and Tools chapter has changed their focus and they do not produce GEs as

such anymore We keep their past roadmap as it was at the end of 2014 for future reference

Roadmap of Developers Community and Tools

Important Note it is important to mention that most (if not all) of the Generic Enabler implementations

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 9

are based on existing baseline assets (open source or proprietary) actively developed and promoted by

the corresponding companies Each company has done internal analysis of requirements and priorities

for each of the technologies based on their business needs and the needs of their customers The goal

of FIWARE is to develop these assets even further to integrate them together to form a coherent

platform and to offer them to the FI-PPP ecosystem for the benefit of the community This roadmap

reflects this approach

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 10

3 Releases and Sprints numbering with mapping to

calendar dates The list of Releases and Sprints together with the time frame of each one of them is depicted in the

following table

Versions

Oct

201

4

No

v

201

4

De

c

201

4

Jan

201

5

Feb

201

5

Ma

r

201

5

Apr

201

5

Ma

y

201

5

Jun

201

5

Jul

201

5

Au

g

201

5

Sep

201

5

Oct

201

5

No

v

201

5

De

c

201

5

Jan

201

6

Feb

201

6

Ma

r

201

6

Apr

201

6

Ma

y

201

6

Jun

201

6

Jul

201

6

Au

g

201

6

Sep

201

6

FIWARE(Clo

sed) Month

Number

M4

2

M4

3

M4

4

FIWARE

Continuatio

n (ongoing)

Month

Number

M2 M3 M4 M5 M6 M7 M8 M9 M1

0

M1

1

M1

2

M1

3

M1

4

M1

5

M1

6

M1

7

M1

8

M1

9

M2

0

M2

1

M2

2

M2

3

M2

4

M2

5

First Major

Release

Second

Major

Release

Third Major

Release

Fourth

Major

Release

41

1

41

2

41

3

42

1

42

2

42

3

43

1

43

2

43

3

44

1

44

2

44

3

Fifth Major

Release

51

1

51

2

51

3

52

1

52

2

52

3

53

1

53

2

53

3

54

1

54

2

54

3

PLEASE NOTE that software associated to Minor Releases may be made available on the FIWARE

Testbed and FIWARE Lab after completing that Minor Release typically by the end of the following

month A revised version of the documentation accompanying software delivered after closing a Minor

Release is also typically delivered by end of the following month

Updates of all FIWARE GEs on the FIWARE Testbed will be planned after each Major Release completion

Besides updates of the FIWARE Testbed may be decided on a more frequent basis at FIWARE GE level

ie the following month after completion of some Sprint

As explained in FIWARE Agile Development Methodology the Releases and Sprints are referred to as

FIWAREReleasexy

FIWARESprintxyz

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 11

4 Roadmap of Internet of Things (IoT) Services

41 Introduction

The Internet of Things Service Enablement chapter in FIWARE provides key assets enabling access to IoT

resources

You can learn more about the IoT Chapter by reading the FIWARE Architecture and Open Specifications

Following is a description of the Technical Roadmap planned for the chapter which will be developed

through subsequent Releases of the FIWARE Platform Please also check the Releases and Sprints

numbering with mapping to calendar dates

42 Fifth Major Release

Following is a description of features per Generic Enablers that will be supported in Release 5 of

FIWARE both in the backend and gateway parts

421 Backend

4211 Backend Device Management

o Addition of new IoT protocols by means of new dedicated IoT Agents Examples

OneM2M (inlcuding MCA northbound interface) amp Modbus

o Development of IoT Agents at the Gateway level Mainly to replace the previous

Protocol Adapater GE

o Deliver new SDKs for different hardware platforms Arduino Cludino Intel Edision

ThinkingThings Open RaspberryPI etc

o Enable new features such as Device Management IoT infrastructure management

(using NGSI entities) etc

o Migration of all IoT Agents to nodejs implementations

4212 Backend IoT Broker

o intelligent update request handling

o efficient and energy saving IoT subsystem invocation

o Enhance interface capabilities

o harmonize additional interface features towards NGSI v2 support

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 12

4213 Backend IoT Discovery

o Support geo-location discovery of entities

o evolve (semantic) linked-data platform API to 2nd version

o evolve NGSI API to 2nd version

o provide ontology for IoT entities

o provide a dataset generator for initial testing

o change store from object database to document store

FIWARE

GE Supported Features Epics under analysis

Backend

Device

Manage

ment

Release 51

FIWAREFeatureIoTIDASModularityHomog

eneousCommands

FIWAREFeatureIoTIDASModularityDevices

Timezone

FIWAREFeatureIoTIDASModularityDeviceL

ifeCicle

FIWAREFeatureIoTIDASModularityDeleteF

unctions

Release 52

FIWAREFeatureIoTIDASProtocolsOneM2M

Basic

FIWAREFeatureIoTIDASDevKitSDKIntelEdis

on

FIWAREFeatureIoTIDASDevKitSDKArduino

Release 53

FIWAREFeatureIoTIDASProtocolsnodejsMi

gration

FIWAREFeatureIoTIDASModularityNewGit

hubOrganization

FIWAREFeatureIoTIDASModularityImprov

eOperations

FIWAREEpicIoTIDASModula

rity

FIWAREEpicIoTIDASProtoc

ols

FIWAREEpicIoTIDASDevKit

FIWAREEpicIoTIDASGeoDes

cription

FIWAREEpicIoTIDASEdgeM

anagement

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 13

Release 54

FIWAREFeatureIoTIDASModularityIoTMan

agerAdvanced

FIWAREFeatureIoTIDASEdgeManagementI

oTInfrastructure

FIWAREFeatureIoTIDASGeoDescriptionPOI

s-Integration

Backend

IoT

Broker

Release 51

FIWAREFeatureIoTBackendIoTBrokerSmart

UpdateHandler

Release 52

FIWAREFeatureIoTBackendIoTBrokerHistor

yQueries

FIWAREFeatureIoTBackendIoTBrokerAdva

ncedQueries

Release 53

FIWAREFeatureIoTBackendIoTBrokerInterf

aceNGSIv2

Release 54

IoT

Discover

y

Release 51

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9GeoLocation

FIWAREFeatureIoTIoTDiscoveryInterfaceS

emanticRegApiV2

FIWAREFeatureIoTIoTDiscoveryRepository

DatasetGenerator

Release 52

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

FIWAREFeatureIoTIoTDiscoveryInterfaceN

FIWAREEpicIoTIoTDiscovery

Interface

FIWAREEpicIoTIoTDiscovery

Interoperability

FIWAREEpicIoTIoTDiscovery

Repository

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 14

gsiV2

Release 53

FIWAREFeatureIoTIoTDiscoveryInterfaceN

gsiV2

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

Release 54

FIWAREFeatureIoTIoTDiscoveryInterface

WebUI

422 Gateway

4221 IoT Data Edge Consolidation

The main effort in release 5 is to be compliant NGSI V2 and to improve the robustness of the broker and

the CEP

o the CEP will offer geofencing operations

o the broker will be compliant ngsi9

o the broker and the CEP will interface with other GE with NGSI V2

FIWAR

E GE Supported Features Epics under analysis

IoT

Data

Edge

Consol

idatio

Release 51

FIWAREFeatureIoTIotDataEdgeConsolidati

onLocalStoragepubsub

FIWAREEpicIoTIotDataEdgeCo

nsolidationLocalStorage

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 15

n FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2GeolocTimes

tamp

FIWAREFeatureIoTIotDataEdgeConsolidati

onBrokerFilterUpdateContext

FIWAREFeatureIoTIotDataEdgeConsolidati

onComplexEventProcessingComplexType

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSI9

Release 52

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2

Release 53

FIWAREFeatureIoTIotDataEdgeConsolidati

onManagerNgsiConfiguration

Release 54

FIWAREFeatureIoTDataEdge-

CepheusNGSI9Operations

FIWAREFeatureIoTDataEdge-

CepheusCEPNGSIConfiguration

FIWAREEpicIoTIotDataEdgeCo

nsolidationBroker

FIWAREEpicIoTIotDataEdgeCo

nsolidationCommonDataModel

FIWAREEpicIoTIotDataEdgeCo

nsolidationComplexEventProce

ssing

FIWAREEpicIoTIotDataEdgeCo

nsolidationManager

43 Future releases

The following features and epics correspond to features that are in the roadmap of the respective

Generic Enablers but are not going to be implemented as part of FIWARE project activities Some of

them may continue under the FIWARE Community activities some others will not

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 16

You can check out the previous releases of this FIWARE chapter on Roadmap of Internet of Things (IoT)

Services(previous releases)

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 17

5 Backend Device Management GE

51 IDAS Modularity Epic

Name Refactoring

IoT Agents

Chapter IoT

Goal Evolution of the architecture and implementation according to developers

feedback

Description To evolve from a C++ monolithic architecture (extensible via C++ plugins) towards

a modular design where each module (IoT Agent) focusses on a reduce set of IoT

Southbound Protocols and is written in any language This will significantly reduce

the complexity of installation and operation of this component

Rationale Lighter architecture and easier installation operation and extensibility The idea is

to provide modules (IoT Agents) for one or a reduced number of IoT southbound

protocols for easier installation and improved operations and scalability

52 IDAS Protocols Epic

Name New

Protocols

- IoT

Agents

Chapter

IoT

Goal Evolution of the architecture and implementation according to industry trends

Description Besides providing backwards compatibility new southbound technologies and

protocols need to be adopted as long as there are new proposals comming from

Industrial alliances and also open and propietary standards that are relavnt

enough to be adopted

Rationale To make FIWARE IoT competitive regarding the latest emerging trends and

industrial propositions The idea behind the IoT agents is to provide such an easy

extensibility and IoT Agents skeletons are provided to developers (in C++ and

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 18

nodejs) so they can also add new protocols if needed

53 IDAS DevKit Epic

Name FIGWAY

Testing

Tools

Chapter

IoT

Goal Provide a set of testing and training tools regarding FIWARE IoT

Description To provide means for experimenting with different kinds of virtual or pyhical

sensor and actuators Particularly virtual sensors emnable simulations and Apps

developmen t before installing devices in place allowing issues antcipation and

improving time to market of IoT projects

Rationale Easy learning testing and training with FIWARE IoT by providing software tools to

be installed in gateways andor laptops desktop PCs etc to perform simulations

54 IDAS GeoDescription Epic

Name Geographical

Description

Chapter IoT

Goal Identify standard methods to add geolocation data to IoT devices so that graphical

representation can be improved

Description Identify standard methods and protocols to add geolocation data to IoT devices so

that graphical representation can be improved Therea re many available options

but the one that is being worked out in the data chapter for the 2D and 3D

interfaces has been finally selected

Rationale Improve graphical presentation of IoT by providing a standar way to add location

metadata to the devices themselves The specification guarantees the

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 19

compatibility with the FIWARE 2D and 3D user interfaces

55 IDAS EdgeManagement Epic

Name IoT Edge

Management

Chapter IoT

Goal Provide an easy way to configure underlaying southbound infrastructure

(gateways networks connectivity security etc)

Description To make the life of IoT providers easier with platform tools So far IDAS was

mainly focussed on translating southbound IoT protocols intro NGSI but this EPIC

will cover the easy deployment and operations of Edge related elements

(gateways connectivity etc)

Rationale The idea behind this EPIC is to make IoT deployments easier and consider the

feedback provided by developers and integrators on this specific area

56 Modularity ndash Homogeneous Commands Feature

Name BE

DeviceManagement

Homogeneous

Commands

Chapter

IoT

Goal Implement the new specs for commands (real-time andor polling) for all IoT

Agents

Description This feature aligns all IoT Agents regarding commands delivery The idea is to

have a common specification for all the ADMIN API and Commands API of the

different IoT Agents

Rationale Provide a common ADMIN API and Commands API for all IoT Agents The

ADMIN API is a REST HTTP API that is similar to the IoT Manager one and it

enables Admins to provision devices services subservices and other

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 20

configurable elements

57 Modularity ndash Devices Timezone Feature

Name BE

DeviceManagement

Device Timezone

Functions

Chapter

IoT

Goal Implement a Timezone function (devices not in GMT) for all IoT Agents

Description This feature aligns all IoT Agents to be able to configure the timezone of

devices The idea is to have a common specification for all the ADMIN API of

the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST

HTTP API that is similar to the IoT Manager one and it enables Admins to

provision devices services subservices and other configurable elements

58 Modularity ndash Device Life Cicle Feature

Name BE

DeviceManagement

Device Life Cicle

Functions

Chapter

IoT

Goal Implement Device Life Cicle functions (enabledisable in addition to

provisiondelete) for all IoT Agents

Description This feature aligns all IoT Agents to be able to manage devices and other

configurable elements (for instance configure a service to accept only pre-

provisioned devices) The idea is to have a common specification for all the

ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 3: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 3

Backend Device Management GE

bull httpwikifiwareorgFIWAREEpicIoTIDASModularity

bull httpwikifiwareorgFIWAREEpicIoTIDASProtocols

bull httpwikifiwareorgFIWAREEpicIoTIDASDevKit

bull httpwikifiwareorgFIWAREEpicIoTIDASGeoDescription

bull httpwikifiwareorgFIWAREEpicIoTIDASEdgeManagement

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityHomogeneousCommands

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityDevicesTimezone

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityDeviceLifeCicle

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityDeleteFunctions

bull httpwikifiwareorgFIWAREFeatureIoTIDASProtocolsOneM2MBasic

bull httpwikifiwareorgFIWAREFeatureIoTIDASDevKitSDKIntelEdison

bull httpwikifiwareorgFIWAREFeatureIoTIDASDevKitSDKArduino

bull httpwikifiwareorgFIWAREFeatureIoTIDASProtocolsnodejsMigration

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityNewGithubOrganization

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityImproveOperations

bull httpwikifiwareorgFIWAREFeatureIoTIDASModularityIoTManagerAdvanced

bull httpwikifiwareorgFIWAREFeatureIoTIDASEdgeManagementIoTInfrastructure

bull httpwikifiwareorgFIWAREFeatureIoTIDASGeoDescriptionPOIs-Integration

IoT Broker GE

bull httpwikifiwareorgFIWAREFeatureIoTBackendIoTBrokerSmartUpdateHandler

bull httpwikifiwareorgFIWAREFeatureIoTBackendIoTBrokerHistoryQueries

bull httpwikifiwareorgFIWAREFeatureIoTBackendIoTBrokerAdvancedQueries

bull httpwikifiwareorgFIWAREFeatureIoTBackendIoTBrokerInterfaceNGSIv2

IoT Discovery GE

bull httpwikifiwareorgFIWAREEpicIoTIoTDiscoveryInterface

bull httpwikifiwareorgFIWAREEpicIoTIoTDiscoveryInteroperability

bull httpwikifiwareorgFIWAREEpicIoTIoTDiscoveryRepository

bull httpwikifiwareorgFIWAREFeatureIoTIoTDiscoveryRepositoryDatasetGenerator

bull httpwikifiwareorgFIWAREFeatureIoTIoTDiscoveryInterfaceSemanticRegApiV2

bull httpwikifiwareorgFIWAREFeatureIoTIoTDiscoveryInterfaceNgsiV2

bull httpwikifiwareorgFIWAREFeatureIoTIoTDiscoveryRepositoryNgsi9OnDocumentS

tore

bull httpwikifiwareorgFIWAREFeatureIoTIoTDiscoveryInterfaceWebUI

bull IoT Data Edge Consolidation GE

bull httpwikifiwareorgFIWAREEpicIoTIotDataEdgeConsolidationLocalStorage

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusBroker

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 4

bull httpwikifiwareorgFIWAREEpicIoTIotDataEdgeConsolidationCommonDataModel

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusCEP

bull httpwikifiwareorgFIWAREEpicIoTIotDataEdgeConsolidationManager

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusNGSIv2

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusNGSIv1

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusNGSI9

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusGUI

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusBrokerPersistentPubSub

bull httpwikifiwareorgFIWAREFeatureIoTIotDataEdgeConsolidationCommonDataMod

elNGSIV2GeolocTimestamp

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-

CepheusBrokerRemoteBrokerFilter

bull httpwikifiwareorgFIWAREFeatureIoTIotDataEdgeConsolidationComplexEventPro

cessingComplexType

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusCEPMultiTenant

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusGUICepConfiguration

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusNGSIv2Basic

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusNGSIv1REST

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusCEPAPIMonitoring

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusNGSI9Operations

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusCEPNGSIConfiguration

The present document has been created from the wiki using automated tools and part of the links may

not work You may occasionally find oddities in the text format that side effects of the process but they

do not deter the quality of the technical contents

15 Keyword list

FIWARE FI-Core Acceleration Programme Accelerators PPP Architecture Board Steering Board

Roadmap Reference Architecture Generic Enabler Open Specifications I2ND Cloud IoT DataMedia

and Context Management ApplicationsServices and Data Delivery Delivery Framework Security

Advanced Middleware Interfaces to Networks and Robotics Communities Tools Sustainability Support

Tools ICT esInternet Apiary Github Latin American Platform

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 5

16 Changes History

Release Major changes description Date Editor

v1 Version for delivery 2015-01-18 Gilles Privat

17 Table of Contents

1 Introduction 2

11 Executive Summary 2

12 About This Document 2

13 Intended Audience 2

14 Structure of this Document 2

15 Keyword list 4

16 Changes History 5

17 Table of Contents 5

2 FIWARE Technical Roadmap 8

3 Releases and Sprints numbering with mapping to calendar dates 10

4 Roadmap of Internet of Things (IoT) Services 11

41 Introduction 11

42 Fifth Major Release 11

421 Backend 11

422 Gateway 14

43 Future releases 15

5 Backend Device Management GE 17

51 IDAS Modularity Epic 17

52 IDAS Protocols Epic 17

53 IDAS DevKit Epic 18

54 IDAS GeoDescription Epic 18

55 IDAS EdgeManagement Epic 19

56 Modularity ndash Homogeneous Commands Feature 19

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 6

57 Modularity ndash Devices Timezone Feature 20

58 Modularity ndash Device Life Cicle Feature 20

59 Modularity ndash Delete Functions Feature 21

510 Protocols - OneM2M Basic Feature 21

511 DevKit ndash SDK Intel Edison Feature 22

512 DevKit ndash SDK Arduino Feature 22

513 Protocols ndash nodejs Migration Feature 22

514 Modularity ndash New Github Organization Feature 23

515 Modularity ndash Improve Operations Feature 23

516 Modularity ndash IoT Manager Advanced Feature 24

517 EdgeManagement ndash IoT Infrastructure Feature 24

518 GeoDescription POIs Integration Feature 25

6 Backend IoT Broker GE 26

61 Smart Update Handler Feature 26

62 History Queries Feature 26

63 Advanced Queries Feature 27

64 Interface NGSIv2 Feature 27

7 Backend IoT Discovery GE 28

71 Interface Epic 28

72 Interoperability Epic 28

73 Repository Epic 29

74 Repository - NGSI9 GeoLocation Feature 29

75 Repository ndash Dataset Generator Feature 30

76 Interface ndash Semantic RegApiv2 Feature 30

77 Interface - NGSIv2 Feature 31

78 Repository - NGSI9 On-Document Store Feature 31

8 IoT Data Edge Consolidation GE 32

81 Local Storage Epic 32

82 DataEdge Cepheus Broker Epic 32

83 Common Data Model Epic 33

84 DataEdge Cepheus CEP Epic 33

85 Manager Epic 33

86 DataEdge Cepheus NGSIv2 Epic 34

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 7

87 DataEdge Cepheus NGSIv1Epic 34

88 DataEdge Cepheus NGSI9 Epic 35

89 DataEdge Cepheus GUI Epic 35

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature 36

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature 36

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature 37

813 Complex Event Processing ndash Complex Type Feature 37

814 Data Edge Cepheus CEP ndash MultiTenant Feature 37

815 Data Edge Cepheus GUI ndash Cep Configuration Feature 38

816 Data Edge Cepheus - NGSIv2 Basic Feature 39

817 Data Edge Cepheus NGSIv1 REST Feature 39

818 Data Edge Cepheus CEP ndash API Monitoring Feature 40

819 Data Edge Cepheus NGSI9 - Operations Feature 40

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature 41

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 8

2 FIWARE Technical Roadmap

FIWAREs technical roadmap brings information about what the different major releases of FIWARE will

bring and when they will be available on FIWARE Lab For each of the FIWARE chapters and for every

generic enabler the list of features available for the particular release is linked within the following

pages You can explore which release number the particular features are currently scheduled for and

contact the affiliated responsible persons in charge if you need more details

The first version of the FIWARE platform was made available on the FIWARE Testbed during 3Q2012 for

experiments by the use case projects within the FI-PPP program The overall goal for this first Release

was to provide a sufficiently complete set of FIWARE GEs which Use Case Projects selected in the first

phase of the FI-PPP program could test and use in their proof of concepts The second release of FIWARE

is focused on integration (both inside and across chapters) as well as evolution of FIWARE GEs based on

feedback from target Users (both Use Case Projects selected in the first phase of the FI-PPP or other

stakeholders like currenttarget customers of FIWARE partners) The third release is focused on

consolidation of the platform and packaging

The fourth and fifth releases will be delivered by a new set of partners (many of them already present in

releases 1 2 and 3) and will bring a reorganization of the map of GEs These GEs will continue building

the core platform ensuring that the results are open and royalty free

Once the development of a given minor release of FIWARE is finished it can be made available on

FIWARE Lab typically by the end of the following month Updates of all FIWARE GEs on FIWARE Lab will

be planned after each major release completion Nevertheless updates of FIWARE Lab may be decided

on a more frequent basis at FIWARE GE level ie the following month after completion of some Sprint

Please check the Releases and Sprints numbering with mapping to calendar dates for further

information

FIWAREs Technical Roadmap is broken into 7 partial roadmaps one per FIWARE Technical Chapter

Roadmap of Cloud Hosting

Roadmap of DataContext Management

Roadmap of Internet of Things (IoT) Services

Roadmap of ApplicationsServices Ecosystem and Delivery Framework

Roadmap of Security

Roadmap of Advanced middleware Interface to Networks and Robotics

Roadmap of Advanced Web-based UI

The Developers Community and Tools chapter has changed their focus and they do not produce GEs as

such anymore We keep their past roadmap as it was at the end of 2014 for future reference

Roadmap of Developers Community and Tools

Important Note it is important to mention that most (if not all) of the Generic Enabler implementations

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 9

are based on existing baseline assets (open source or proprietary) actively developed and promoted by

the corresponding companies Each company has done internal analysis of requirements and priorities

for each of the technologies based on their business needs and the needs of their customers The goal

of FIWARE is to develop these assets even further to integrate them together to form a coherent

platform and to offer them to the FI-PPP ecosystem for the benefit of the community This roadmap

reflects this approach

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 10

3 Releases and Sprints numbering with mapping to

calendar dates The list of Releases and Sprints together with the time frame of each one of them is depicted in the

following table

Versions

Oct

201

4

No

v

201

4

De

c

201

4

Jan

201

5

Feb

201

5

Ma

r

201

5

Apr

201

5

Ma

y

201

5

Jun

201

5

Jul

201

5

Au

g

201

5

Sep

201

5

Oct

201

5

No

v

201

5

De

c

201

5

Jan

201

6

Feb

201

6

Ma

r

201

6

Apr

201

6

Ma

y

201

6

Jun

201

6

Jul

201

6

Au

g

201

6

Sep

201

6

FIWARE(Clo

sed) Month

Number

M4

2

M4

3

M4

4

FIWARE

Continuatio

n (ongoing)

Month

Number

M2 M3 M4 M5 M6 M7 M8 M9 M1

0

M1

1

M1

2

M1

3

M1

4

M1

5

M1

6

M1

7

M1

8

M1

9

M2

0

M2

1

M2

2

M2

3

M2

4

M2

5

First Major

Release

Second

Major

Release

Third Major

Release

Fourth

Major

Release

41

1

41

2

41

3

42

1

42

2

42

3

43

1

43

2

43

3

44

1

44

2

44

3

Fifth Major

Release

51

1

51

2

51

3

52

1

52

2

52

3

53

1

53

2

53

3

54

1

54

2

54

3

PLEASE NOTE that software associated to Minor Releases may be made available on the FIWARE

Testbed and FIWARE Lab after completing that Minor Release typically by the end of the following

month A revised version of the documentation accompanying software delivered after closing a Minor

Release is also typically delivered by end of the following month

Updates of all FIWARE GEs on the FIWARE Testbed will be planned after each Major Release completion

Besides updates of the FIWARE Testbed may be decided on a more frequent basis at FIWARE GE level

ie the following month after completion of some Sprint

As explained in FIWARE Agile Development Methodology the Releases and Sprints are referred to as

FIWAREReleasexy

FIWARESprintxyz

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 11

4 Roadmap of Internet of Things (IoT) Services

41 Introduction

The Internet of Things Service Enablement chapter in FIWARE provides key assets enabling access to IoT

resources

You can learn more about the IoT Chapter by reading the FIWARE Architecture and Open Specifications

Following is a description of the Technical Roadmap planned for the chapter which will be developed

through subsequent Releases of the FIWARE Platform Please also check the Releases and Sprints

numbering with mapping to calendar dates

42 Fifth Major Release

Following is a description of features per Generic Enablers that will be supported in Release 5 of

FIWARE both in the backend and gateway parts

421 Backend

4211 Backend Device Management

o Addition of new IoT protocols by means of new dedicated IoT Agents Examples

OneM2M (inlcuding MCA northbound interface) amp Modbus

o Development of IoT Agents at the Gateway level Mainly to replace the previous

Protocol Adapater GE

o Deliver new SDKs for different hardware platforms Arduino Cludino Intel Edision

ThinkingThings Open RaspberryPI etc

o Enable new features such as Device Management IoT infrastructure management

(using NGSI entities) etc

o Migration of all IoT Agents to nodejs implementations

4212 Backend IoT Broker

o intelligent update request handling

o efficient and energy saving IoT subsystem invocation

o Enhance interface capabilities

o harmonize additional interface features towards NGSI v2 support

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 12

4213 Backend IoT Discovery

o Support geo-location discovery of entities

o evolve (semantic) linked-data platform API to 2nd version

o evolve NGSI API to 2nd version

o provide ontology for IoT entities

o provide a dataset generator for initial testing

o change store from object database to document store

FIWARE

GE Supported Features Epics under analysis

Backend

Device

Manage

ment

Release 51

FIWAREFeatureIoTIDASModularityHomog

eneousCommands

FIWAREFeatureIoTIDASModularityDevices

Timezone

FIWAREFeatureIoTIDASModularityDeviceL

ifeCicle

FIWAREFeatureIoTIDASModularityDeleteF

unctions

Release 52

FIWAREFeatureIoTIDASProtocolsOneM2M

Basic

FIWAREFeatureIoTIDASDevKitSDKIntelEdis

on

FIWAREFeatureIoTIDASDevKitSDKArduino

Release 53

FIWAREFeatureIoTIDASProtocolsnodejsMi

gration

FIWAREFeatureIoTIDASModularityNewGit

hubOrganization

FIWAREFeatureIoTIDASModularityImprov

eOperations

FIWAREEpicIoTIDASModula

rity

FIWAREEpicIoTIDASProtoc

ols

FIWAREEpicIoTIDASDevKit

FIWAREEpicIoTIDASGeoDes

cription

FIWAREEpicIoTIDASEdgeM

anagement

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 13

Release 54

FIWAREFeatureIoTIDASModularityIoTMan

agerAdvanced

FIWAREFeatureIoTIDASEdgeManagementI

oTInfrastructure

FIWAREFeatureIoTIDASGeoDescriptionPOI

s-Integration

Backend

IoT

Broker

Release 51

FIWAREFeatureIoTBackendIoTBrokerSmart

UpdateHandler

Release 52

FIWAREFeatureIoTBackendIoTBrokerHistor

yQueries

FIWAREFeatureIoTBackendIoTBrokerAdva

ncedQueries

Release 53

FIWAREFeatureIoTBackendIoTBrokerInterf

aceNGSIv2

Release 54

IoT

Discover

y

Release 51

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9GeoLocation

FIWAREFeatureIoTIoTDiscoveryInterfaceS

emanticRegApiV2

FIWAREFeatureIoTIoTDiscoveryRepository

DatasetGenerator

Release 52

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

FIWAREFeatureIoTIoTDiscoveryInterfaceN

FIWAREEpicIoTIoTDiscovery

Interface

FIWAREEpicIoTIoTDiscovery

Interoperability

FIWAREEpicIoTIoTDiscovery

Repository

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 14

gsiV2

Release 53

FIWAREFeatureIoTIoTDiscoveryInterfaceN

gsiV2

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

Release 54

FIWAREFeatureIoTIoTDiscoveryInterface

WebUI

422 Gateway

4221 IoT Data Edge Consolidation

The main effort in release 5 is to be compliant NGSI V2 and to improve the robustness of the broker and

the CEP

o the CEP will offer geofencing operations

o the broker will be compliant ngsi9

o the broker and the CEP will interface with other GE with NGSI V2

FIWAR

E GE Supported Features Epics under analysis

IoT

Data

Edge

Consol

idatio

Release 51

FIWAREFeatureIoTIotDataEdgeConsolidati

onLocalStoragepubsub

FIWAREEpicIoTIotDataEdgeCo

nsolidationLocalStorage

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 15

n FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2GeolocTimes

tamp

FIWAREFeatureIoTIotDataEdgeConsolidati

onBrokerFilterUpdateContext

FIWAREFeatureIoTIotDataEdgeConsolidati

onComplexEventProcessingComplexType

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSI9

Release 52

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2

Release 53

FIWAREFeatureIoTIotDataEdgeConsolidati

onManagerNgsiConfiguration

Release 54

FIWAREFeatureIoTDataEdge-

CepheusNGSI9Operations

FIWAREFeatureIoTDataEdge-

CepheusCEPNGSIConfiguration

FIWAREEpicIoTIotDataEdgeCo

nsolidationBroker

FIWAREEpicIoTIotDataEdgeCo

nsolidationCommonDataModel

FIWAREEpicIoTIotDataEdgeCo

nsolidationComplexEventProce

ssing

FIWAREEpicIoTIotDataEdgeCo

nsolidationManager

43 Future releases

The following features and epics correspond to features that are in the roadmap of the respective

Generic Enablers but are not going to be implemented as part of FIWARE project activities Some of

them may continue under the FIWARE Community activities some others will not

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 16

You can check out the previous releases of this FIWARE chapter on Roadmap of Internet of Things (IoT)

Services(previous releases)

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 17

5 Backend Device Management GE

51 IDAS Modularity Epic

Name Refactoring

IoT Agents

Chapter IoT

Goal Evolution of the architecture and implementation according to developers

feedback

Description To evolve from a C++ monolithic architecture (extensible via C++ plugins) towards

a modular design where each module (IoT Agent) focusses on a reduce set of IoT

Southbound Protocols and is written in any language This will significantly reduce

the complexity of installation and operation of this component

Rationale Lighter architecture and easier installation operation and extensibility The idea is

to provide modules (IoT Agents) for one or a reduced number of IoT southbound

protocols for easier installation and improved operations and scalability

52 IDAS Protocols Epic

Name New

Protocols

- IoT

Agents

Chapter

IoT

Goal Evolution of the architecture and implementation according to industry trends

Description Besides providing backwards compatibility new southbound technologies and

protocols need to be adopted as long as there are new proposals comming from

Industrial alliances and also open and propietary standards that are relavnt

enough to be adopted

Rationale To make FIWARE IoT competitive regarding the latest emerging trends and

industrial propositions The idea behind the IoT agents is to provide such an easy

extensibility and IoT Agents skeletons are provided to developers (in C++ and

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 18

nodejs) so they can also add new protocols if needed

53 IDAS DevKit Epic

Name FIGWAY

Testing

Tools

Chapter

IoT

Goal Provide a set of testing and training tools regarding FIWARE IoT

Description To provide means for experimenting with different kinds of virtual or pyhical

sensor and actuators Particularly virtual sensors emnable simulations and Apps

developmen t before installing devices in place allowing issues antcipation and

improving time to market of IoT projects

Rationale Easy learning testing and training with FIWARE IoT by providing software tools to

be installed in gateways andor laptops desktop PCs etc to perform simulations

54 IDAS GeoDescription Epic

Name Geographical

Description

Chapter IoT

Goal Identify standard methods to add geolocation data to IoT devices so that graphical

representation can be improved

Description Identify standard methods and protocols to add geolocation data to IoT devices so

that graphical representation can be improved Therea re many available options

but the one that is being worked out in the data chapter for the 2D and 3D

interfaces has been finally selected

Rationale Improve graphical presentation of IoT by providing a standar way to add location

metadata to the devices themselves The specification guarantees the

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 19

compatibility with the FIWARE 2D and 3D user interfaces

55 IDAS EdgeManagement Epic

Name IoT Edge

Management

Chapter IoT

Goal Provide an easy way to configure underlaying southbound infrastructure

(gateways networks connectivity security etc)

Description To make the life of IoT providers easier with platform tools So far IDAS was

mainly focussed on translating southbound IoT protocols intro NGSI but this EPIC

will cover the easy deployment and operations of Edge related elements

(gateways connectivity etc)

Rationale The idea behind this EPIC is to make IoT deployments easier and consider the

feedback provided by developers and integrators on this specific area

56 Modularity ndash Homogeneous Commands Feature

Name BE

DeviceManagement

Homogeneous

Commands

Chapter

IoT

Goal Implement the new specs for commands (real-time andor polling) for all IoT

Agents

Description This feature aligns all IoT Agents regarding commands delivery The idea is to

have a common specification for all the ADMIN API and Commands API of the

different IoT Agents

Rationale Provide a common ADMIN API and Commands API for all IoT Agents The

ADMIN API is a REST HTTP API that is similar to the IoT Manager one and it

enables Admins to provision devices services subservices and other

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 20

configurable elements

57 Modularity ndash Devices Timezone Feature

Name BE

DeviceManagement

Device Timezone

Functions

Chapter

IoT

Goal Implement a Timezone function (devices not in GMT) for all IoT Agents

Description This feature aligns all IoT Agents to be able to configure the timezone of

devices The idea is to have a common specification for all the ADMIN API of

the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST

HTTP API that is similar to the IoT Manager one and it enables Admins to

provision devices services subservices and other configurable elements

58 Modularity ndash Device Life Cicle Feature

Name BE

DeviceManagement

Device Life Cicle

Functions

Chapter

IoT

Goal Implement Device Life Cicle functions (enabledisable in addition to

provisiondelete) for all IoT Agents

Description This feature aligns all IoT Agents to be able to manage devices and other

configurable elements (for instance configure a service to accept only pre-

provisioned devices) The idea is to have a common specification for all the

ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 4: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 4

bull httpwikifiwareorgFIWAREEpicIoTIotDataEdgeConsolidationCommonDataModel

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusCEP

bull httpwikifiwareorgFIWAREEpicIoTIotDataEdgeConsolidationManager

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusNGSIv2

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusNGSIv1

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusNGSI9

bull httpwikifiwareorgFIWAREEpicIoTDataEdge-CepheusGUI

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusBrokerPersistentPubSub

bull httpwikifiwareorgFIWAREFeatureIoTIotDataEdgeConsolidationCommonDataMod

elNGSIV2GeolocTimestamp

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-

CepheusBrokerRemoteBrokerFilter

bull httpwikifiwareorgFIWAREFeatureIoTIotDataEdgeConsolidationComplexEventPro

cessingComplexType

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusCEPMultiTenant

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusGUICepConfiguration

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusNGSIv2Basic

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusNGSIv1REST

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusCEPAPIMonitoring

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusNGSI9Operations

bull httpwikifiwareorgFIWAREFeatureIoTDataEdge-CepheusCEPNGSIConfiguration

The present document has been created from the wiki using automated tools and part of the links may

not work You may occasionally find oddities in the text format that side effects of the process but they

do not deter the quality of the technical contents

15 Keyword list

FIWARE FI-Core Acceleration Programme Accelerators PPP Architecture Board Steering Board

Roadmap Reference Architecture Generic Enabler Open Specifications I2ND Cloud IoT DataMedia

and Context Management ApplicationsServices and Data Delivery Delivery Framework Security

Advanced Middleware Interfaces to Networks and Robotics Communities Tools Sustainability Support

Tools ICT esInternet Apiary Github Latin American Platform

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 5

16 Changes History

Release Major changes description Date Editor

v1 Version for delivery 2015-01-18 Gilles Privat

17 Table of Contents

1 Introduction 2

11 Executive Summary 2

12 About This Document 2

13 Intended Audience 2

14 Structure of this Document 2

15 Keyword list 4

16 Changes History 5

17 Table of Contents 5

2 FIWARE Technical Roadmap 8

3 Releases and Sprints numbering with mapping to calendar dates 10

4 Roadmap of Internet of Things (IoT) Services 11

41 Introduction 11

42 Fifth Major Release 11

421 Backend 11

422 Gateway 14

43 Future releases 15

5 Backend Device Management GE 17

51 IDAS Modularity Epic 17

52 IDAS Protocols Epic 17

53 IDAS DevKit Epic 18

54 IDAS GeoDescription Epic 18

55 IDAS EdgeManagement Epic 19

56 Modularity ndash Homogeneous Commands Feature 19

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 6

57 Modularity ndash Devices Timezone Feature 20

58 Modularity ndash Device Life Cicle Feature 20

59 Modularity ndash Delete Functions Feature 21

510 Protocols - OneM2M Basic Feature 21

511 DevKit ndash SDK Intel Edison Feature 22

512 DevKit ndash SDK Arduino Feature 22

513 Protocols ndash nodejs Migration Feature 22

514 Modularity ndash New Github Organization Feature 23

515 Modularity ndash Improve Operations Feature 23

516 Modularity ndash IoT Manager Advanced Feature 24

517 EdgeManagement ndash IoT Infrastructure Feature 24

518 GeoDescription POIs Integration Feature 25

6 Backend IoT Broker GE 26

61 Smart Update Handler Feature 26

62 History Queries Feature 26

63 Advanced Queries Feature 27

64 Interface NGSIv2 Feature 27

7 Backend IoT Discovery GE 28

71 Interface Epic 28

72 Interoperability Epic 28

73 Repository Epic 29

74 Repository - NGSI9 GeoLocation Feature 29

75 Repository ndash Dataset Generator Feature 30

76 Interface ndash Semantic RegApiv2 Feature 30

77 Interface - NGSIv2 Feature 31

78 Repository - NGSI9 On-Document Store Feature 31

8 IoT Data Edge Consolidation GE 32

81 Local Storage Epic 32

82 DataEdge Cepheus Broker Epic 32

83 Common Data Model Epic 33

84 DataEdge Cepheus CEP Epic 33

85 Manager Epic 33

86 DataEdge Cepheus NGSIv2 Epic 34

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 7

87 DataEdge Cepheus NGSIv1Epic 34

88 DataEdge Cepheus NGSI9 Epic 35

89 DataEdge Cepheus GUI Epic 35

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature 36

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature 36

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature 37

813 Complex Event Processing ndash Complex Type Feature 37

814 Data Edge Cepheus CEP ndash MultiTenant Feature 37

815 Data Edge Cepheus GUI ndash Cep Configuration Feature 38

816 Data Edge Cepheus - NGSIv2 Basic Feature 39

817 Data Edge Cepheus NGSIv1 REST Feature 39

818 Data Edge Cepheus CEP ndash API Monitoring Feature 40

819 Data Edge Cepheus NGSI9 - Operations Feature 40

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature 41

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 8

2 FIWARE Technical Roadmap

FIWAREs technical roadmap brings information about what the different major releases of FIWARE will

bring and when they will be available on FIWARE Lab For each of the FIWARE chapters and for every

generic enabler the list of features available for the particular release is linked within the following

pages You can explore which release number the particular features are currently scheduled for and

contact the affiliated responsible persons in charge if you need more details

The first version of the FIWARE platform was made available on the FIWARE Testbed during 3Q2012 for

experiments by the use case projects within the FI-PPP program The overall goal for this first Release

was to provide a sufficiently complete set of FIWARE GEs which Use Case Projects selected in the first

phase of the FI-PPP program could test and use in their proof of concepts The second release of FIWARE

is focused on integration (both inside and across chapters) as well as evolution of FIWARE GEs based on

feedback from target Users (both Use Case Projects selected in the first phase of the FI-PPP or other

stakeholders like currenttarget customers of FIWARE partners) The third release is focused on

consolidation of the platform and packaging

The fourth and fifth releases will be delivered by a new set of partners (many of them already present in

releases 1 2 and 3) and will bring a reorganization of the map of GEs These GEs will continue building

the core platform ensuring that the results are open and royalty free

Once the development of a given minor release of FIWARE is finished it can be made available on

FIWARE Lab typically by the end of the following month Updates of all FIWARE GEs on FIWARE Lab will

be planned after each major release completion Nevertheless updates of FIWARE Lab may be decided

on a more frequent basis at FIWARE GE level ie the following month after completion of some Sprint

Please check the Releases and Sprints numbering with mapping to calendar dates for further

information

FIWAREs Technical Roadmap is broken into 7 partial roadmaps one per FIWARE Technical Chapter

Roadmap of Cloud Hosting

Roadmap of DataContext Management

Roadmap of Internet of Things (IoT) Services

Roadmap of ApplicationsServices Ecosystem and Delivery Framework

Roadmap of Security

Roadmap of Advanced middleware Interface to Networks and Robotics

Roadmap of Advanced Web-based UI

The Developers Community and Tools chapter has changed their focus and they do not produce GEs as

such anymore We keep their past roadmap as it was at the end of 2014 for future reference

Roadmap of Developers Community and Tools

Important Note it is important to mention that most (if not all) of the Generic Enabler implementations

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 9

are based on existing baseline assets (open source or proprietary) actively developed and promoted by

the corresponding companies Each company has done internal analysis of requirements and priorities

for each of the technologies based on their business needs and the needs of their customers The goal

of FIWARE is to develop these assets even further to integrate them together to form a coherent

platform and to offer them to the FI-PPP ecosystem for the benefit of the community This roadmap

reflects this approach

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 10

3 Releases and Sprints numbering with mapping to

calendar dates The list of Releases and Sprints together with the time frame of each one of them is depicted in the

following table

Versions

Oct

201

4

No

v

201

4

De

c

201

4

Jan

201

5

Feb

201

5

Ma

r

201

5

Apr

201

5

Ma

y

201

5

Jun

201

5

Jul

201

5

Au

g

201

5

Sep

201

5

Oct

201

5

No

v

201

5

De

c

201

5

Jan

201

6

Feb

201

6

Ma

r

201

6

Apr

201

6

Ma

y

201

6

Jun

201

6

Jul

201

6

Au

g

201

6

Sep

201

6

FIWARE(Clo

sed) Month

Number

M4

2

M4

3

M4

4

FIWARE

Continuatio

n (ongoing)

Month

Number

M2 M3 M4 M5 M6 M7 M8 M9 M1

0

M1

1

M1

2

M1

3

M1

4

M1

5

M1

6

M1

7

M1

8

M1

9

M2

0

M2

1

M2

2

M2

3

M2

4

M2

5

First Major

Release

Second

Major

Release

Third Major

Release

Fourth

Major

Release

41

1

41

2

41

3

42

1

42

2

42

3

43

1

43

2

43

3

44

1

44

2

44

3

Fifth Major

Release

51

1

51

2

51

3

52

1

52

2

52

3

53

1

53

2

53

3

54

1

54

2

54

3

PLEASE NOTE that software associated to Minor Releases may be made available on the FIWARE

Testbed and FIWARE Lab after completing that Minor Release typically by the end of the following

month A revised version of the documentation accompanying software delivered after closing a Minor

Release is also typically delivered by end of the following month

Updates of all FIWARE GEs on the FIWARE Testbed will be planned after each Major Release completion

Besides updates of the FIWARE Testbed may be decided on a more frequent basis at FIWARE GE level

ie the following month after completion of some Sprint

As explained in FIWARE Agile Development Methodology the Releases and Sprints are referred to as

FIWAREReleasexy

FIWARESprintxyz

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 11

4 Roadmap of Internet of Things (IoT) Services

41 Introduction

The Internet of Things Service Enablement chapter in FIWARE provides key assets enabling access to IoT

resources

You can learn more about the IoT Chapter by reading the FIWARE Architecture and Open Specifications

Following is a description of the Technical Roadmap planned for the chapter which will be developed

through subsequent Releases of the FIWARE Platform Please also check the Releases and Sprints

numbering with mapping to calendar dates

42 Fifth Major Release

Following is a description of features per Generic Enablers that will be supported in Release 5 of

FIWARE both in the backend and gateway parts

421 Backend

4211 Backend Device Management

o Addition of new IoT protocols by means of new dedicated IoT Agents Examples

OneM2M (inlcuding MCA northbound interface) amp Modbus

o Development of IoT Agents at the Gateway level Mainly to replace the previous

Protocol Adapater GE

o Deliver new SDKs for different hardware platforms Arduino Cludino Intel Edision

ThinkingThings Open RaspberryPI etc

o Enable new features such as Device Management IoT infrastructure management

(using NGSI entities) etc

o Migration of all IoT Agents to nodejs implementations

4212 Backend IoT Broker

o intelligent update request handling

o efficient and energy saving IoT subsystem invocation

o Enhance interface capabilities

o harmonize additional interface features towards NGSI v2 support

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 12

4213 Backend IoT Discovery

o Support geo-location discovery of entities

o evolve (semantic) linked-data platform API to 2nd version

o evolve NGSI API to 2nd version

o provide ontology for IoT entities

o provide a dataset generator for initial testing

o change store from object database to document store

FIWARE

GE Supported Features Epics under analysis

Backend

Device

Manage

ment

Release 51

FIWAREFeatureIoTIDASModularityHomog

eneousCommands

FIWAREFeatureIoTIDASModularityDevices

Timezone

FIWAREFeatureIoTIDASModularityDeviceL

ifeCicle

FIWAREFeatureIoTIDASModularityDeleteF

unctions

Release 52

FIWAREFeatureIoTIDASProtocolsOneM2M

Basic

FIWAREFeatureIoTIDASDevKitSDKIntelEdis

on

FIWAREFeatureIoTIDASDevKitSDKArduino

Release 53

FIWAREFeatureIoTIDASProtocolsnodejsMi

gration

FIWAREFeatureIoTIDASModularityNewGit

hubOrganization

FIWAREFeatureIoTIDASModularityImprov

eOperations

FIWAREEpicIoTIDASModula

rity

FIWAREEpicIoTIDASProtoc

ols

FIWAREEpicIoTIDASDevKit

FIWAREEpicIoTIDASGeoDes

cription

FIWAREEpicIoTIDASEdgeM

anagement

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 13

Release 54

FIWAREFeatureIoTIDASModularityIoTMan

agerAdvanced

FIWAREFeatureIoTIDASEdgeManagementI

oTInfrastructure

FIWAREFeatureIoTIDASGeoDescriptionPOI

s-Integration

Backend

IoT

Broker

Release 51

FIWAREFeatureIoTBackendIoTBrokerSmart

UpdateHandler

Release 52

FIWAREFeatureIoTBackendIoTBrokerHistor

yQueries

FIWAREFeatureIoTBackendIoTBrokerAdva

ncedQueries

Release 53

FIWAREFeatureIoTBackendIoTBrokerInterf

aceNGSIv2

Release 54

IoT

Discover

y

Release 51

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9GeoLocation

FIWAREFeatureIoTIoTDiscoveryInterfaceS

emanticRegApiV2

FIWAREFeatureIoTIoTDiscoveryRepository

DatasetGenerator

Release 52

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

FIWAREFeatureIoTIoTDiscoveryInterfaceN

FIWAREEpicIoTIoTDiscovery

Interface

FIWAREEpicIoTIoTDiscovery

Interoperability

FIWAREEpicIoTIoTDiscovery

Repository

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 14

gsiV2

Release 53

FIWAREFeatureIoTIoTDiscoveryInterfaceN

gsiV2

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

Release 54

FIWAREFeatureIoTIoTDiscoveryInterface

WebUI

422 Gateway

4221 IoT Data Edge Consolidation

The main effort in release 5 is to be compliant NGSI V2 and to improve the robustness of the broker and

the CEP

o the CEP will offer geofencing operations

o the broker will be compliant ngsi9

o the broker and the CEP will interface with other GE with NGSI V2

FIWAR

E GE Supported Features Epics under analysis

IoT

Data

Edge

Consol

idatio

Release 51

FIWAREFeatureIoTIotDataEdgeConsolidati

onLocalStoragepubsub

FIWAREEpicIoTIotDataEdgeCo

nsolidationLocalStorage

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 15

n FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2GeolocTimes

tamp

FIWAREFeatureIoTIotDataEdgeConsolidati

onBrokerFilterUpdateContext

FIWAREFeatureIoTIotDataEdgeConsolidati

onComplexEventProcessingComplexType

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSI9

Release 52

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2

Release 53

FIWAREFeatureIoTIotDataEdgeConsolidati

onManagerNgsiConfiguration

Release 54

FIWAREFeatureIoTDataEdge-

CepheusNGSI9Operations

FIWAREFeatureIoTDataEdge-

CepheusCEPNGSIConfiguration

FIWAREEpicIoTIotDataEdgeCo

nsolidationBroker

FIWAREEpicIoTIotDataEdgeCo

nsolidationCommonDataModel

FIWAREEpicIoTIotDataEdgeCo

nsolidationComplexEventProce

ssing

FIWAREEpicIoTIotDataEdgeCo

nsolidationManager

43 Future releases

The following features and epics correspond to features that are in the roadmap of the respective

Generic Enablers but are not going to be implemented as part of FIWARE project activities Some of

them may continue under the FIWARE Community activities some others will not

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 16

You can check out the previous releases of this FIWARE chapter on Roadmap of Internet of Things (IoT)

Services(previous releases)

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 17

5 Backend Device Management GE

51 IDAS Modularity Epic

Name Refactoring

IoT Agents

Chapter IoT

Goal Evolution of the architecture and implementation according to developers

feedback

Description To evolve from a C++ monolithic architecture (extensible via C++ plugins) towards

a modular design where each module (IoT Agent) focusses on a reduce set of IoT

Southbound Protocols and is written in any language This will significantly reduce

the complexity of installation and operation of this component

Rationale Lighter architecture and easier installation operation and extensibility The idea is

to provide modules (IoT Agents) for one or a reduced number of IoT southbound

protocols for easier installation and improved operations and scalability

52 IDAS Protocols Epic

Name New

Protocols

- IoT

Agents

Chapter

IoT

Goal Evolution of the architecture and implementation according to industry trends

Description Besides providing backwards compatibility new southbound technologies and

protocols need to be adopted as long as there are new proposals comming from

Industrial alliances and also open and propietary standards that are relavnt

enough to be adopted

Rationale To make FIWARE IoT competitive regarding the latest emerging trends and

industrial propositions The idea behind the IoT agents is to provide such an easy

extensibility and IoT Agents skeletons are provided to developers (in C++ and

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 18

nodejs) so they can also add new protocols if needed

53 IDAS DevKit Epic

Name FIGWAY

Testing

Tools

Chapter

IoT

Goal Provide a set of testing and training tools regarding FIWARE IoT

Description To provide means for experimenting with different kinds of virtual or pyhical

sensor and actuators Particularly virtual sensors emnable simulations and Apps

developmen t before installing devices in place allowing issues antcipation and

improving time to market of IoT projects

Rationale Easy learning testing and training with FIWARE IoT by providing software tools to

be installed in gateways andor laptops desktop PCs etc to perform simulations

54 IDAS GeoDescription Epic

Name Geographical

Description

Chapter IoT

Goal Identify standard methods to add geolocation data to IoT devices so that graphical

representation can be improved

Description Identify standard methods and protocols to add geolocation data to IoT devices so

that graphical representation can be improved Therea re many available options

but the one that is being worked out in the data chapter for the 2D and 3D

interfaces has been finally selected

Rationale Improve graphical presentation of IoT by providing a standar way to add location

metadata to the devices themselves The specification guarantees the

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 19

compatibility with the FIWARE 2D and 3D user interfaces

55 IDAS EdgeManagement Epic

Name IoT Edge

Management

Chapter IoT

Goal Provide an easy way to configure underlaying southbound infrastructure

(gateways networks connectivity security etc)

Description To make the life of IoT providers easier with platform tools So far IDAS was

mainly focussed on translating southbound IoT protocols intro NGSI but this EPIC

will cover the easy deployment and operations of Edge related elements

(gateways connectivity etc)

Rationale The idea behind this EPIC is to make IoT deployments easier and consider the

feedback provided by developers and integrators on this specific area

56 Modularity ndash Homogeneous Commands Feature

Name BE

DeviceManagement

Homogeneous

Commands

Chapter

IoT

Goal Implement the new specs for commands (real-time andor polling) for all IoT

Agents

Description This feature aligns all IoT Agents regarding commands delivery The idea is to

have a common specification for all the ADMIN API and Commands API of the

different IoT Agents

Rationale Provide a common ADMIN API and Commands API for all IoT Agents The

ADMIN API is a REST HTTP API that is similar to the IoT Manager one and it

enables Admins to provision devices services subservices and other

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 20

configurable elements

57 Modularity ndash Devices Timezone Feature

Name BE

DeviceManagement

Device Timezone

Functions

Chapter

IoT

Goal Implement a Timezone function (devices not in GMT) for all IoT Agents

Description This feature aligns all IoT Agents to be able to configure the timezone of

devices The idea is to have a common specification for all the ADMIN API of

the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST

HTTP API that is similar to the IoT Manager one and it enables Admins to

provision devices services subservices and other configurable elements

58 Modularity ndash Device Life Cicle Feature

Name BE

DeviceManagement

Device Life Cicle

Functions

Chapter

IoT

Goal Implement Device Life Cicle functions (enabledisable in addition to

provisiondelete) for all IoT Agents

Description This feature aligns all IoT Agents to be able to manage devices and other

configurable elements (for instance configure a service to accept only pre-

provisioned devices) The idea is to have a common specification for all the

ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 5: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 5

16 Changes History

Release Major changes description Date Editor

v1 Version for delivery 2015-01-18 Gilles Privat

17 Table of Contents

1 Introduction 2

11 Executive Summary 2

12 About This Document 2

13 Intended Audience 2

14 Structure of this Document 2

15 Keyword list 4

16 Changes History 5

17 Table of Contents 5

2 FIWARE Technical Roadmap 8

3 Releases and Sprints numbering with mapping to calendar dates 10

4 Roadmap of Internet of Things (IoT) Services 11

41 Introduction 11

42 Fifth Major Release 11

421 Backend 11

422 Gateway 14

43 Future releases 15

5 Backend Device Management GE 17

51 IDAS Modularity Epic 17

52 IDAS Protocols Epic 17

53 IDAS DevKit Epic 18

54 IDAS GeoDescription Epic 18

55 IDAS EdgeManagement Epic 19

56 Modularity ndash Homogeneous Commands Feature 19

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 6

57 Modularity ndash Devices Timezone Feature 20

58 Modularity ndash Device Life Cicle Feature 20

59 Modularity ndash Delete Functions Feature 21

510 Protocols - OneM2M Basic Feature 21

511 DevKit ndash SDK Intel Edison Feature 22

512 DevKit ndash SDK Arduino Feature 22

513 Protocols ndash nodejs Migration Feature 22

514 Modularity ndash New Github Organization Feature 23

515 Modularity ndash Improve Operations Feature 23

516 Modularity ndash IoT Manager Advanced Feature 24

517 EdgeManagement ndash IoT Infrastructure Feature 24

518 GeoDescription POIs Integration Feature 25

6 Backend IoT Broker GE 26

61 Smart Update Handler Feature 26

62 History Queries Feature 26

63 Advanced Queries Feature 27

64 Interface NGSIv2 Feature 27

7 Backend IoT Discovery GE 28

71 Interface Epic 28

72 Interoperability Epic 28

73 Repository Epic 29

74 Repository - NGSI9 GeoLocation Feature 29

75 Repository ndash Dataset Generator Feature 30

76 Interface ndash Semantic RegApiv2 Feature 30

77 Interface - NGSIv2 Feature 31

78 Repository - NGSI9 On-Document Store Feature 31

8 IoT Data Edge Consolidation GE 32

81 Local Storage Epic 32

82 DataEdge Cepheus Broker Epic 32

83 Common Data Model Epic 33

84 DataEdge Cepheus CEP Epic 33

85 Manager Epic 33

86 DataEdge Cepheus NGSIv2 Epic 34

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 7

87 DataEdge Cepheus NGSIv1Epic 34

88 DataEdge Cepheus NGSI9 Epic 35

89 DataEdge Cepheus GUI Epic 35

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature 36

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature 36

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature 37

813 Complex Event Processing ndash Complex Type Feature 37

814 Data Edge Cepheus CEP ndash MultiTenant Feature 37

815 Data Edge Cepheus GUI ndash Cep Configuration Feature 38

816 Data Edge Cepheus - NGSIv2 Basic Feature 39

817 Data Edge Cepheus NGSIv1 REST Feature 39

818 Data Edge Cepheus CEP ndash API Monitoring Feature 40

819 Data Edge Cepheus NGSI9 - Operations Feature 40

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature 41

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 8

2 FIWARE Technical Roadmap

FIWAREs technical roadmap brings information about what the different major releases of FIWARE will

bring and when they will be available on FIWARE Lab For each of the FIWARE chapters and for every

generic enabler the list of features available for the particular release is linked within the following

pages You can explore which release number the particular features are currently scheduled for and

contact the affiliated responsible persons in charge if you need more details

The first version of the FIWARE platform was made available on the FIWARE Testbed during 3Q2012 for

experiments by the use case projects within the FI-PPP program The overall goal for this first Release

was to provide a sufficiently complete set of FIWARE GEs which Use Case Projects selected in the first

phase of the FI-PPP program could test and use in their proof of concepts The second release of FIWARE

is focused on integration (both inside and across chapters) as well as evolution of FIWARE GEs based on

feedback from target Users (both Use Case Projects selected in the first phase of the FI-PPP or other

stakeholders like currenttarget customers of FIWARE partners) The third release is focused on

consolidation of the platform and packaging

The fourth and fifth releases will be delivered by a new set of partners (many of them already present in

releases 1 2 and 3) and will bring a reorganization of the map of GEs These GEs will continue building

the core platform ensuring that the results are open and royalty free

Once the development of a given minor release of FIWARE is finished it can be made available on

FIWARE Lab typically by the end of the following month Updates of all FIWARE GEs on FIWARE Lab will

be planned after each major release completion Nevertheless updates of FIWARE Lab may be decided

on a more frequent basis at FIWARE GE level ie the following month after completion of some Sprint

Please check the Releases and Sprints numbering with mapping to calendar dates for further

information

FIWAREs Technical Roadmap is broken into 7 partial roadmaps one per FIWARE Technical Chapter

Roadmap of Cloud Hosting

Roadmap of DataContext Management

Roadmap of Internet of Things (IoT) Services

Roadmap of ApplicationsServices Ecosystem and Delivery Framework

Roadmap of Security

Roadmap of Advanced middleware Interface to Networks and Robotics

Roadmap of Advanced Web-based UI

The Developers Community and Tools chapter has changed their focus and they do not produce GEs as

such anymore We keep their past roadmap as it was at the end of 2014 for future reference

Roadmap of Developers Community and Tools

Important Note it is important to mention that most (if not all) of the Generic Enabler implementations

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 9

are based on existing baseline assets (open source or proprietary) actively developed and promoted by

the corresponding companies Each company has done internal analysis of requirements and priorities

for each of the technologies based on their business needs and the needs of their customers The goal

of FIWARE is to develop these assets even further to integrate them together to form a coherent

platform and to offer them to the FI-PPP ecosystem for the benefit of the community This roadmap

reflects this approach

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 10

3 Releases and Sprints numbering with mapping to

calendar dates The list of Releases and Sprints together with the time frame of each one of them is depicted in the

following table

Versions

Oct

201

4

No

v

201

4

De

c

201

4

Jan

201

5

Feb

201

5

Ma

r

201

5

Apr

201

5

Ma

y

201

5

Jun

201

5

Jul

201

5

Au

g

201

5

Sep

201

5

Oct

201

5

No

v

201

5

De

c

201

5

Jan

201

6

Feb

201

6

Ma

r

201

6

Apr

201

6

Ma

y

201

6

Jun

201

6

Jul

201

6

Au

g

201

6

Sep

201

6

FIWARE(Clo

sed) Month

Number

M4

2

M4

3

M4

4

FIWARE

Continuatio

n (ongoing)

Month

Number

M2 M3 M4 M5 M6 M7 M8 M9 M1

0

M1

1

M1

2

M1

3

M1

4

M1

5

M1

6

M1

7

M1

8

M1

9

M2

0

M2

1

M2

2

M2

3

M2

4

M2

5

First Major

Release

Second

Major

Release

Third Major

Release

Fourth

Major

Release

41

1

41

2

41

3

42

1

42

2

42

3

43

1

43

2

43

3

44

1

44

2

44

3

Fifth Major

Release

51

1

51

2

51

3

52

1

52

2

52

3

53

1

53

2

53

3

54

1

54

2

54

3

PLEASE NOTE that software associated to Minor Releases may be made available on the FIWARE

Testbed and FIWARE Lab after completing that Minor Release typically by the end of the following

month A revised version of the documentation accompanying software delivered after closing a Minor

Release is also typically delivered by end of the following month

Updates of all FIWARE GEs on the FIWARE Testbed will be planned after each Major Release completion

Besides updates of the FIWARE Testbed may be decided on a more frequent basis at FIWARE GE level

ie the following month after completion of some Sprint

As explained in FIWARE Agile Development Methodology the Releases and Sprints are referred to as

FIWAREReleasexy

FIWARESprintxyz

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 11

4 Roadmap of Internet of Things (IoT) Services

41 Introduction

The Internet of Things Service Enablement chapter in FIWARE provides key assets enabling access to IoT

resources

You can learn more about the IoT Chapter by reading the FIWARE Architecture and Open Specifications

Following is a description of the Technical Roadmap planned for the chapter which will be developed

through subsequent Releases of the FIWARE Platform Please also check the Releases and Sprints

numbering with mapping to calendar dates

42 Fifth Major Release

Following is a description of features per Generic Enablers that will be supported in Release 5 of

FIWARE both in the backend and gateway parts

421 Backend

4211 Backend Device Management

o Addition of new IoT protocols by means of new dedicated IoT Agents Examples

OneM2M (inlcuding MCA northbound interface) amp Modbus

o Development of IoT Agents at the Gateway level Mainly to replace the previous

Protocol Adapater GE

o Deliver new SDKs for different hardware platforms Arduino Cludino Intel Edision

ThinkingThings Open RaspberryPI etc

o Enable new features such as Device Management IoT infrastructure management

(using NGSI entities) etc

o Migration of all IoT Agents to nodejs implementations

4212 Backend IoT Broker

o intelligent update request handling

o efficient and energy saving IoT subsystem invocation

o Enhance interface capabilities

o harmonize additional interface features towards NGSI v2 support

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 12

4213 Backend IoT Discovery

o Support geo-location discovery of entities

o evolve (semantic) linked-data platform API to 2nd version

o evolve NGSI API to 2nd version

o provide ontology for IoT entities

o provide a dataset generator for initial testing

o change store from object database to document store

FIWARE

GE Supported Features Epics under analysis

Backend

Device

Manage

ment

Release 51

FIWAREFeatureIoTIDASModularityHomog

eneousCommands

FIWAREFeatureIoTIDASModularityDevices

Timezone

FIWAREFeatureIoTIDASModularityDeviceL

ifeCicle

FIWAREFeatureIoTIDASModularityDeleteF

unctions

Release 52

FIWAREFeatureIoTIDASProtocolsOneM2M

Basic

FIWAREFeatureIoTIDASDevKitSDKIntelEdis

on

FIWAREFeatureIoTIDASDevKitSDKArduino

Release 53

FIWAREFeatureIoTIDASProtocolsnodejsMi

gration

FIWAREFeatureIoTIDASModularityNewGit

hubOrganization

FIWAREFeatureIoTIDASModularityImprov

eOperations

FIWAREEpicIoTIDASModula

rity

FIWAREEpicIoTIDASProtoc

ols

FIWAREEpicIoTIDASDevKit

FIWAREEpicIoTIDASGeoDes

cription

FIWAREEpicIoTIDASEdgeM

anagement

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 13

Release 54

FIWAREFeatureIoTIDASModularityIoTMan

agerAdvanced

FIWAREFeatureIoTIDASEdgeManagementI

oTInfrastructure

FIWAREFeatureIoTIDASGeoDescriptionPOI

s-Integration

Backend

IoT

Broker

Release 51

FIWAREFeatureIoTBackendIoTBrokerSmart

UpdateHandler

Release 52

FIWAREFeatureIoTBackendIoTBrokerHistor

yQueries

FIWAREFeatureIoTBackendIoTBrokerAdva

ncedQueries

Release 53

FIWAREFeatureIoTBackendIoTBrokerInterf

aceNGSIv2

Release 54

IoT

Discover

y

Release 51

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9GeoLocation

FIWAREFeatureIoTIoTDiscoveryInterfaceS

emanticRegApiV2

FIWAREFeatureIoTIoTDiscoveryRepository

DatasetGenerator

Release 52

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

FIWAREFeatureIoTIoTDiscoveryInterfaceN

FIWAREEpicIoTIoTDiscovery

Interface

FIWAREEpicIoTIoTDiscovery

Interoperability

FIWAREEpicIoTIoTDiscovery

Repository

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 14

gsiV2

Release 53

FIWAREFeatureIoTIoTDiscoveryInterfaceN

gsiV2

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

Release 54

FIWAREFeatureIoTIoTDiscoveryInterface

WebUI

422 Gateway

4221 IoT Data Edge Consolidation

The main effort in release 5 is to be compliant NGSI V2 and to improve the robustness of the broker and

the CEP

o the CEP will offer geofencing operations

o the broker will be compliant ngsi9

o the broker and the CEP will interface with other GE with NGSI V2

FIWAR

E GE Supported Features Epics under analysis

IoT

Data

Edge

Consol

idatio

Release 51

FIWAREFeatureIoTIotDataEdgeConsolidati

onLocalStoragepubsub

FIWAREEpicIoTIotDataEdgeCo

nsolidationLocalStorage

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 15

n FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2GeolocTimes

tamp

FIWAREFeatureIoTIotDataEdgeConsolidati

onBrokerFilterUpdateContext

FIWAREFeatureIoTIotDataEdgeConsolidati

onComplexEventProcessingComplexType

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSI9

Release 52

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2

Release 53

FIWAREFeatureIoTIotDataEdgeConsolidati

onManagerNgsiConfiguration

Release 54

FIWAREFeatureIoTDataEdge-

CepheusNGSI9Operations

FIWAREFeatureIoTDataEdge-

CepheusCEPNGSIConfiguration

FIWAREEpicIoTIotDataEdgeCo

nsolidationBroker

FIWAREEpicIoTIotDataEdgeCo

nsolidationCommonDataModel

FIWAREEpicIoTIotDataEdgeCo

nsolidationComplexEventProce

ssing

FIWAREEpicIoTIotDataEdgeCo

nsolidationManager

43 Future releases

The following features and epics correspond to features that are in the roadmap of the respective

Generic Enablers but are not going to be implemented as part of FIWARE project activities Some of

them may continue under the FIWARE Community activities some others will not

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 16

You can check out the previous releases of this FIWARE chapter on Roadmap of Internet of Things (IoT)

Services(previous releases)

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 17

5 Backend Device Management GE

51 IDAS Modularity Epic

Name Refactoring

IoT Agents

Chapter IoT

Goal Evolution of the architecture and implementation according to developers

feedback

Description To evolve from a C++ monolithic architecture (extensible via C++ plugins) towards

a modular design where each module (IoT Agent) focusses on a reduce set of IoT

Southbound Protocols and is written in any language This will significantly reduce

the complexity of installation and operation of this component

Rationale Lighter architecture and easier installation operation and extensibility The idea is

to provide modules (IoT Agents) for one or a reduced number of IoT southbound

protocols for easier installation and improved operations and scalability

52 IDAS Protocols Epic

Name New

Protocols

- IoT

Agents

Chapter

IoT

Goal Evolution of the architecture and implementation according to industry trends

Description Besides providing backwards compatibility new southbound technologies and

protocols need to be adopted as long as there are new proposals comming from

Industrial alliances and also open and propietary standards that are relavnt

enough to be adopted

Rationale To make FIWARE IoT competitive regarding the latest emerging trends and

industrial propositions The idea behind the IoT agents is to provide such an easy

extensibility and IoT Agents skeletons are provided to developers (in C++ and

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 18

nodejs) so they can also add new protocols if needed

53 IDAS DevKit Epic

Name FIGWAY

Testing

Tools

Chapter

IoT

Goal Provide a set of testing and training tools regarding FIWARE IoT

Description To provide means for experimenting with different kinds of virtual or pyhical

sensor and actuators Particularly virtual sensors emnable simulations and Apps

developmen t before installing devices in place allowing issues antcipation and

improving time to market of IoT projects

Rationale Easy learning testing and training with FIWARE IoT by providing software tools to

be installed in gateways andor laptops desktop PCs etc to perform simulations

54 IDAS GeoDescription Epic

Name Geographical

Description

Chapter IoT

Goal Identify standard methods to add geolocation data to IoT devices so that graphical

representation can be improved

Description Identify standard methods and protocols to add geolocation data to IoT devices so

that graphical representation can be improved Therea re many available options

but the one that is being worked out in the data chapter for the 2D and 3D

interfaces has been finally selected

Rationale Improve graphical presentation of IoT by providing a standar way to add location

metadata to the devices themselves The specification guarantees the

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 19

compatibility with the FIWARE 2D and 3D user interfaces

55 IDAS EdgeManagement Epic

Name IoT Edge

Management

Chapter IoT

Goal Provide an easy way to configure underlaying southbound infrastructure

(gateways networks connectivity security etc)

Description To make the life of IoT providers easier with platform tools So far IDAS was

mainly focussed on translating southbound IoT protocols intro NGSI but this EPIC

will cover the easy deployment and operations of Edge related elements

(gateways connectivity etc)

Rationale The idea behind this EPIC is to make IoT deployments easier and consider the

feedback provided by developers and integrators on this specific area

56 Modularity ndash Homogeneous Commands Feature

Name BE

DeviceManagement

Homogeneous

Commands

Chapter

IoT

Goal Implement the new specs for commands (real-time andor polling) for all IoT

Agents

Description This feature aligns all IoT Agents regarding commands delivery The idea is to

have a common specification for all the ADMIN API and Commands API of the

different IoT Agents

Rationale Provide a common ADMIN API and Commands API for all IoT Agents The

ADMIN API is a REST HTTP API that is similar to the IoT Manager one and it

enables Admins to provision devices services subservices and other

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 20

configurable elements

57 Modularity ndash Devices Timezone Feature

Name BE

DeviceManagement

Device Timezone

Functions

Chapter

IoT

Goal Implement a Timezone function (devices not in GMT) for all IoT Agents

Description This feature aligns all IoT Agents to be able to configure the timezone of

devices The idea is to have a common specification for all the ADMIN API of

the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST

HTTP API that is similar to the IoT Manager one and it enables Admins to

provision devices services subservices and other configurable elements

58 Modularity ndash Device Life Cicle Feature

Name BE

DeviceManagement

Device Life Cicle

Functions

Chapter

IoT

Goal Implement Device Life Cicle functions (enabledisable in addition to

provisiondelete) for all IoT Agents

Description This feature aligns all IoT Agents to be able to manage devices and other

configurable elements (for instance configure a service to accept only pre-

provisioned devices) The idea is to have a common specification for all the

ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 6: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 6

57 Modularity ndash Devices Timezone Feature 20

58 Modularity ndash Device Life Cicle Feature 20

59 Modularity ndash Delete Functions Feature 21

510 Protocols - OneM2M Basic Feature 21

511 DevKit ndash SDK Intel Edison Feature 22

512 DevKit ndash SDK Arduino Feature 22

513 Protocols ndash nodejs Migration Feature 22

514 Modularity ndash New Github Organization Feature 23

515 Modularity ndash Improve Operations Feature 23

516 Modularity ndash IoT Manager Advanced Feature 24

517 EdgeManagement ndash IoT Infrastructure Feature 24

518 GeoDescription POIs Integration Feature 25

6 Backend IoT Broker GE 26

61 Smart Update Handler Feature 26

62 History Queries Feature 26

63 Advanced Queries Feature 27

64 Interface NGSIv2 Feature 27

7 Backend IoT Discovery GE 28

71 Interface Epic 28

72 Interoperability Epic 28

73 Repository Epic 29

74 Repository - NGSI9 GeoLocation Feature 29

75 Repository ndash Dataset Generator Feature 30

76 Interface ndash Semantic RegApiv2 Feature 30

77 Interface - NGSIv2 Feature 31

78 Repository - NGSI9 On-Document Store Feature 31

8 IoT Data Edge Consolidation GE 32

81 Local Storage Epic 32

82 DataEdge Cepheus Broker Epic 32

83 Common Data Model Epic 33

84 DataEdge Cepheus CEP Epic 33

85 Manager Epic 33

86 DataEdge Cepheus NGSIv2 Epic 34

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 7

87 DataEdge Cepheus NGSIv1Epic 34

88 DataEdge Cepheus NGSI9 Epic 35

89 DataEdge Cepheus GUI Epic 35

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature 36

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature 36

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature 37

813 Complex Event Processing ndash Complex Type Feature 37

814 Data Edge Cepheus CEP ndash MultiTenant Feature 37

815 Data Edge Cepheus GUI ndash Cep Configuration Feature 38

816 Data Edge Cepheus - NGSIv2 Basic Feature 39

817 Data Edge Cepheus NGSIv1 REST Feature 39

818 Data Edge Cepheus CEP ndash API Monitoring Feature 40

819 Data Edge Cepheus NGSI9 - Operations Feature 40

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature 41

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 8

2 FIWARE Technical Roadmap

FIWAREs technical roadmap brings information about what the different major releases of FIWARE will

bring and when they will be available on FIWARE Lab For each of the FIWARE chapters and for every

generic enabler the list of features available for the particular release is linked within the following

pages You can explore which release number the particular features are currently scheduled for and

contact the affiliated responsible persons in charge if you need more details

The first version of the FIWARE platform was made available on the FIWARE Testbed during 3Q2012 for

experiments by the use case projects within the FI-PPP program The overall goal for this first Release

was to provide a sufficiently complete set of FIWARE GEs which Use Case Projects selected in the first

phase of the FI-PPP program could test and use in their proof of concepts The second release of FIWARE

is focused on integration (both inside and across chapters) as well as evolution of FIWARE GEs based on

feedback from target Users (both Use Case Projects selected in the first phase of the FI-PPP or other

stakeholders like currenttarget customers of FIWARE partners) The third release is focused on

consolidation of the platform and packaging

The fourth and fifth releases will be delivered by a new set of partners (many of them already present in

releases 1 2 and 3) and will bring a reorganization of the map of GEs These GEs will continue building

the core platform ensuring that the results are open and royalty free

Once the development of a given minor release of FIWARE is finished it can be made available on

FIWARE Lab typically by the end of the following month Updates of all FIWARE GEs on FIWARE Lab will

be planned after each major release completion Nevertheless updates of FIWARE Lab may be decided

on a more frequent basis at FIWARE GE level ie the following month after completion of some Sprint

Please check the Releases and Sprints numbering with mapping to calendar dates for further

information

FIWAREs Technical Roadmap is broken into 7 partial roadmaps one per FIWARE Technical Chapter

Roadmap of Cloud Hosting

Roadmap of DataContext Management

Roadmap of Internet of Things (IoT) Services

Roadmap of ApplicationsServices Ecosystem and Delivery Framework

Roadmap of Security

Roadmap of Advanced middleware Interface to Networks and Robotics

Roadmap of Advanced Web-based UI

The Developers Community and Tools chapter has changed their focus and they do not produce GEs as

such anymore We keep their past roadmap as it was at the end of 2014 for future reference

Roadmap of Developers Community and Tools

Important Note it is important to mention that most (if not all) of the Generic Enabler implementations

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 9

are based on existing baseline assets (open source or proprietary) actively developed and promoted by

the corresponding companies Each company has done internal analysis of requirements and priorities

for each of the technologies based on their business needs and the needs of their customers The goal

of FIWARE is to develop these assets even further to integrate them together to form a coherent

platform and to offer them to the FI-PPP ecosystem for the benefit of the community This roadmap

reflects this approach

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 10

3 Releases and Sprints numbering with mapping to

calendar dates The list of Releases and Sprints together with the time frame of each one of them is depicted in the

following table

Versions

Oct

201

4

No

v

201

4

De

c

201

4

Jan

201

5

Feb

201

5

Ma

r

201

5

Apr

201

5

Ma

y

201

5

Jun

201

5

Jul

201

5

Au

g

201

5

Sep

201

5

Oct

201

5

No

v

201

5

De

c

201

5

Jan

201

6

Feb

201

6

Ma

r

201

6

Apr

201

6

Ma

y

201

6

Jun

201

6

Jul

201

6

Au

g

201

6

Sep

201

6

FIWARE(Clo

sed) Month

Number

M4

2

M4

3

M4

4

FIWARE

Continuatio

n (ongoing)

Month

Number

M2 M3 M4 M5 M6 M7 M8 M9 M1

0

M1

1

M1

2

M1

3

M1

4

M1

5

M1

6

M1

7

M1

8

M1

9

M2

0

M2

1

M2

2

M2

3

M2

4

M2

5

First Major

Release

Second

Major

Release

Third Major

Release

Fourth

Major

Release

41

1

41

2

41

3

42

1

42

2

42

3

43

1

43

2

43

3

44

1

44

2

44

3

Fifth Major

Release

51

1

51

2

51

3

52

1

52

2

52

3

53

1

53

2

53

3

54

1

54

2

54

3

PLEASE NOTE that software associated to Minor Releases may be made available on the FIWARE

Testbed and FIWARE Lab after completing that Minor Release typically by the end of the following

month A revised version of the documentation accompanying software delivered after closing a Minor

Release is also typically delivered by end of the following month

Updates of all FIWARE GEs on the FIWARE Testbed will be planned after each Major Release completion

Besides updates of the FIWARE Testbed may be decided on a more frequent basis at FIWARE GE level

ie the following month after completion of some Sprint

As explained in FIWARE Agile Development Methodology the Releases and Sprints are referred to as

FIWAREReleasexy

FIWARESprintxyz

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 11

4 Roadmap of Internet of Things (IoT) Services

41 Introduction

The Internet of Things Service Enablement chapter in FIWARE provides key assets enabling access to IoT

resources

You can learn more about the IoT Chapter by reading the FIWARE Architecture and Open Specifications

Following is a description of the Technical Roadmap planned for the chapter which will be developed

through subsequent Releases of the FIWARE Platform Please also check the Releases and Sprints

numbering with mapping to calendar dates

42 Fifth Major Release

Following is a description of features per Generic Enablers that will be supported in Release 5 of

FIWARE both in the backend and gateway parts

421 Backend

4211 Backend Device Management

o Addition of new IoT protocols by means of new dedicated IoT Agents Examples

OneM2M (inlcuding MCA northbound interface) amp Modbus

o Development of IoT Agents at the Gateway level Mainly to replace the previous

Protocol Adapater GE

o Deliver new SDKs for different hardware platforms Arduino Cludino Intel Edision

ThinkingThings Open RaspberryPI etc

o Enable new features such as Device Management IoT infrastructure management

(using NGSI entities) etc

o Migration of all IoT Agents to nodejs implementations

4212 Backend IoT Broker

o intelligent update request handling

o efficient and energy saving IoT subsystem invocation

o Enhance interface capabilities

o harmonize additional interface features towards NGSI v2 support

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 12

4213 Backend IoT Discovery

o Support geo-location discovery of entities

o evolve (semantic) linked-data platform API to 2nd version

o evolve NGSI API to 2nd version

o provide ontology for IoT entities

o provide a dataset generator for initial testing

o change store from object database to document store

FIWARE

GE Supported Features Epics under analysis

Backend

Device

Manage

ment

Release 51

FIWAREFeatureIoTIDASModularityHomog

eneousCommands

FIWAREFeatureIoTIDASModularityDevices

Timezone

FIWAREFeatureIoTIDASModularityDeviceL

ifeCicle

FIWAREFeatureIoTIDASModularityDeleteF

unctions

Release 52

FIWAREFeatureIoTIDASProtocolsOneM2M

Basic

FIWAREFeatureIoTIDASDevKitSDKIntelEdis

on

FIWAREFeatureIoTIDASDevKitSDKArduino

Release 53

FIWAREFeatureIoTIDASProtocolsnodejsMi

gration

FIWAREFeatureIoTIDASModularityNewGit

hubOrganization

FIWAREFeatureIoTIDASModularityImprov

eOperations

FIWAREEpicIoTIDASModula

rity

FIWAREEpicIoTIDASProtoc

ols

FIWAREEpicIoTIDASDevKit

FIWAREEpicIoTIDASGeoDes

cription

FIWAREEpicIoTIDASEdgeM

anagement

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 13

Release 54

FIWAREFeatureIoTIDASModularityIoTMan

agerAdvanced

FIWAREFeatureIoTIDASEdgeManagementI

oTInfrastructure

FIWAREFeatureIoTIDASGeoDescriptionPOI

s-Integration

Backend

IoT

Broker

Release 51

FIWAREFeatureIoTBackendIoTBrokerSmart

UpdateHandler

Release 52

FIWAREFeatureIoTBackendIoTBrokerHistor

yQueries

FIWAREFeatureIoTBackendIoTBrokerAdva

ncedQueries

Release 53

FIWAREFeatureIoTBackendIoTBrokerInterf

aceNGSIv2

Release 54

IoT

Discover

y

Release 51

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9GeoLocation

FIWAREFeatureIoTIoTDiscoveryInterfaceS

emanticRegApiV2

FIWAREFeatureIoTIoTDiscoveryRepository

DatasetGenerator

Release 52

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

FIWAREFeatureIoTIoTDiscoveryInterfaceN

FIWAREEpicIoTIoTDiscovery

Interface

FIWAREEpicIoTIoTDiscovery

Interoperability

FIWAREEpicIoTIoTDiscovery

Repository

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 14

gsiV2

Release 53

FIWAREFeatureIoTIoTDiscoveryInterfaceN

gsiV2

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

Release 54

FIWAREFeatureIoTIoTDiscoveryInterface

WebUI

422 Gateway

4221 IoT Data Edge Consolidation

The main effort in release 5 is to be compliant NGSI V2 and to improve the robustness of the broker and

the CEP

o the CEP will offer geofencing operations

o the broker will be compliant ngsi9

o the broker and the CEP will interface with other GE with NGSI V2

FIWAR

E GE Supported Features Epics under analysis

IoT

Data

Edge

Consol

idatio

Release 51

FIWAREFeatureIoTIotDataEdgeConsolidati

onLocalStoragepubsub

FIWAREEpicIoTIotDataEdgeCo

nsolidationLocalStorage

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 15

n FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2GeolocTimes

tamp

FIWAREFeatureIoTIotDataEdgeConsolidati

onBrokerFilterUpdateContext

FIWAREFeatureIoTIotDataEdgeConsolidati

onComplexEventProcessingComplexType

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSI9

Release 52

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2

Release 53

FIWAREFeatureIoTIotDataEdgeConsolidati

onManagerNgsiConfiguration

Release 54

FIWAREFeatureIoTDataEdge-

CepheusNGSI9Operations

FIWAREFeatureIoTDataEdge-

CepheusCEPNGSIConfiguration

FIWAREEpicIoTIotDataEdgeCo

nsolidationBroker

FIWAREEpicIoTIotDataEdgeCo

nsolidationCommonDataModel

FIWAREEpicIoTIotDataEdgeCo

nsolidationComplexEventProce

ssing

FIWAREEpicIoTIotDataEdgeCo

nsolidationManager

43 Future releases

The following features and epics correspond to features that are in the roadmap of the respective

Generic Enablers but are not going to be implemented as part of FIWARE project activities Some of

them may continue under the FIWARE Community activities some others will not

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 16

You can check out the previous releases of this FIWARE chapter on Roadmap of Internet of Things (IoT)

Services(previous releases)

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 17

5 Backend Device Management GE

51 IDAS Modularity Epic

Name Refactoring

IoT Agents

Chapter IoT

Goal Evolution of the architecture and implementation according to developers

feedback

Description To evolve from a C++ monolithic architecture (extensible via C++ plugins) towards

a modular design where each module (IoT Agent) focusses on a reduce set of IoT

Southbound Protocols and is written in any language This will significantly reduce

the complexity of installation and operation of this component

Rationale Lighter architecture and easier installation operation and extensibility The idea is

to provide modules (IoT Agents) for one or a reduced number of IoT southbound

protocols for easier installation and improved operations and scalability

52 IDAS Protocols Epic

Name New

Protocols

- IoT

Agents

Chapter

IoT

Goal Evolution of the architecture and implementation according to industry trends

Description Besides providing backwards compatibility new southbound technologies and

protocols need to be adopted as long as there are new proposals comming from

Industrial alliances and also open and propietary standards that are relavnt

enough to be adopted

Rationale To make FIWARE IoT competitive regarding the latest emerging trends and

industrial propositions The idea behind the IoT agents is to provide such an easy

extensibility and IoT Agents skeletons are provided to developers (in C++ and

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 18

nodejs) so they can also add new protocols if needed

53 IDAS DevKit Epic

Name FIGWAY

Testing

Tools

Chapter

IoT

Goal Provide a set of testing and training tools regarding FIWARE IoT

Description To provide means for experimenting with different kinds of virtual or pyhical

sensor and actuators Particularly virtual sensors emnable simulations and Apps

developmen t before installing devices in place allowing issues antcipation and

improving time to market of IoT projects

Rationale Easy learning testing and training with FIWARE IoT by providing software tools to

be installed in gateways andor laptops desktop PCs etc to perform simulations

54 IDAS GeoDescription Epic

Name Geographical

Description

Chapter IoT

Goal Identify standard methods to add geolocation data to IoT devices so that graphical

representation can be improved

Description Identify standard methods and protocols to add geolocation data to IoT devices so

that graphical representation can be improved Therea re many available options

but the one that is being worked out in the data chapter for the 2D and 3D

interfaces has been finally selected

Rationale Improve graphical presentation of IoT by providing a standar way to add location

metadata to the devices themselves The specification guarantees the

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 19

compatibility with the FIWARE 2D and 3D user interfaces

55 IDAS EdgeManagement Epic

Name IoT Edge

Management

Chapter IoT

Goal Provide an easy way to configure underlaying southbound infrastructure

(gateways networks connectivity security etc)

Description To make the life of IoT providers easier with platform tools So far IDAS was

mainly focussed on translating southbound IoT protocols intro NGSI but this EPIC

will cover the easy deployment and operations of Edge related elements

(gateways connectivity etc)

Rationale The idea behind this EPIC is to make IoT deployments easier and consider the

feedback provided by developers and integrators on this specific area

56 Modularity ndash Homogeneous Commands Feature

Name BE

DeviceManagement

Homogeneous

Commands

Chapter

IoT

Goal Implement the new specs for commands (real-time andor polling) for all IoT

Agents

Description This feature aligns all IoT Agents regarding commands delivery The idea is to

have a common specification for all the ADMIN API and Commands API of the

different IoT Agents

Rationale Provide a common ADMIN API and Commands API for all IoT Agents The

ADMIN API is a REST HTTP API that is similar to the IoT Manager one and it

enables Admins to provision devices services subservices and other

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 20

configurable elements

57 Modularity ndash Devices Timezone Feature

Name BE

DeviceManagement

Device Timezone

Functions

Chapter

IoT

Goal Implement a Timezone function (devices not in GMT) for all IoT Agents

Description This feature aligns all IoT Agents to be able to configure the timezone of

devices The idea is to have a common specification for all the ADMIN API of

the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST

HTTP API that is similar to the IoT Manager one and it enables Admins to

provision devices services subservices and other configurable elements

58 Modularity ndash Device Life Cicle Feature

Name BE

DeviceManagement

Device Life Cicle

Functions

Chapter

IoT

Goal Implement Device Life Cicle functions (enabledisable in addition to

provisiondelete) for all IoT Agents

Description This feature aligns all IoT Agents to be able to manage devices and other

configurable elements (for instance configure a service to accept only pre-

provisioned devices) The idea is to have a common specification for all the

ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 7: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 7

87 DataEdge Cepheus NGSIv1Epic 34

88 DataEdge Cepheus NGSI9 Epic 35

89 DataEdge Cepheus GUI Epic 35

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature 36

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature 36

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature 37

813 Complex Event Processing ndash Complex Type Feature 37

814 Data Edge Cepheus CEP ndash MultiTenant Feature 37

815 Data Edge Cepheus GUI ndash Cep Configuration Feature 38

816 Data Edge Cepheus - NGSIv2 Basic Feature 39

817 Data Edge Cepheus NGSIv1 REST Feature 39

818 Data Edge Cepheus CEP ndash API Monitoring Feature 40

819 Data Edge Cepheus NGSI9 - Operations Feature 40

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature 41

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 8

2 FIWARE Technical Roadmap

FIWAREs technical roadmap brings information about what the different major releases of FIWARE will

bring and when they will be available on FIWARE Lab For each of the FIWARE chapters and for every

generic enabler the list of features available for the particular release is linked within the following

pages You can explore which release number the particular features are currently scheduled for and

contact the affiliated responsible persons in charge if you need more details

The first version of the FIWARE platform was made available on the FIWARE Testbed during 3Q2012 for

experiments by the use case projects within the FI-PPP program The overall goal for this first Release

was to provide a sufficiently complete set of FIWARE GEs which Use Case Projects selected in the first

phase of the FI-PPP program could test and use in their proof of concepts The second release of FIWARE

is focused on integration (both inside and across chapters) as well as evolution of FIWARE GEs based on

feedback from target Users (both Use Case Projects selected in the first phase of the FI-PPP or other

stakeholders like currenttarget customers of FIWARE partners) The third release is focused on

consolidation of the platform and packaging

The fourth and fifth releases will be delivered by a new set of partners (many of them already present in

releases 1 2 and 3) and will bring a reorganization of the map of GEs These GEs will continue building

the core platform ensuring that the results are open and royalty free

Once the development of a given minor release of FIWARE is finished it can be made available on

FIWARE Lab typically by the end of the following month Updates of all FIWARE GEs on FIWARE Lab will

be planned after each major release completion Nevertheless updates of FIWARE Lab may be decided

on a more frequent basis at FIWARE GE level ie the following month after completion of some Sprint

Please check the Releases and Sprints numbering with mapping to calendar dates for further

information

FIWAREs Technical Roadmap is broken into 7 partial roadmaps one per FIWARE Technical Chapter

Roadmap of Cloud Hosting

Roadmap of DataContext Management

Roadmap of Internet of Things (IoT) Services

Roadmap of ApplicationsServices Ecosystem and Delivery Framework

Roadmap of Security

Roadmap of Advanced middleware Interface to Networks and Robotics

Roadmap of Advanced Web-based UI

The Developers Community and Tools chapter has changed their focus and they do not produce GEs as

such anymore We keep their past roadmap as it was at the end of 2014 for future reference

Roadmap of Developers Community and Tools

Important Note it is important to mention that most (if not all) of the Generic Enabler implementations

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 9

are based on existing baseline assets (open source or proprietary) actively developed and promoted by

the corresponding companies Each company has done internal analysis of requirements and priorities

for each of the technologies based on their business needs and the needs of their customers The goal

of FIWARE is to develop these assets even further to integrate them together to form a coherent

platform and to offer them to the FI-PPP ecosystem for the benefit of the community This roadmap

reflects this approach

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 10

3 Releases and Sprints numbering with mapping to

calendar dates The list of Releases and Sprints together with the time frame of each one of them is depicted in the

following table

Versions

Oct

201

4

No

v

201

4

De

c

201

4

Jan

201

5

Feb

201

5

Ma

r

201

5

Apr

201

5

Ma

y

201

5

Jun

201

5

Jul

201

5

Au

g

201

5

Sep

201

5

Oct

201

5

No

v

201

5

De

c

201

5

Jan

201

6

Feb

201

6

Ma

r

201

6

Apr

201

6

Ma

y

201

6

Jun

201

6

Jul

201

6

Au

g

201

6

Sep

201

6

FIWARE(Clo

sed) Month

Number

M4

2

M4

3

M4

4

FIWARE

Continuatio

n (ongoing)

Month

Number

M2 M3 M4 M5 M6 M7 M8 M9 M1

0

M1

1

M1

2

M1

3

M1

4

M1

5

M1

6

M1

7

M1

8

M1

9

M2

0

M2

1

M2

2

M2

3

M2

4

M2

5

First Major

Release

Second

Major

Release

Third Major

Release

Fourth

Major

Release

41

1

41

2

41

3

42

1

42

2

42

3

43

1

43

2

43

3

44

1

44

2

44

3

Fifth Major

Release

51

1

51

2

51

3

52

1

52

2

52

3

53

1

53

2

53

3

54

1

54

2

54

3

PLEASE NOTE that software associated to Minor Releases may be made available on the FIWARE

Testbed and FIWARE Lab after completing that Minor Release typically by the end of the following

month A revised version of the documentation accompanying software delivered after closing a Minor

Release is also typically delivered by end of the following month

Updates of all FIWARE GEs on the FIWARE Testbed will be planned after each Major Release completion

Besides updates of the FIWARE Testbed may be decided on a more frequent basis at FIWARE GE level

ie the following month after completion of some Sprint

As explained in FIWARE Agile Development Methodology the Releases and Sprints are referred to as

FIWAREReleasexy

FIWARESprintxyz

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 11

4 Roadmap of Internet of Things (IoT) Services

41 Introduction

The Internet of Things Service Enablement chapter in FIWARE provides key assets enabling access to IoT

resources

You can learn more about the IoT Chapter by reading the FIWARE Architecture and Open Specifications

Following is a description of the Technical Roadmap planned for the chapter which will be developed

through subsequent Releases of the FIWARE Platform Please also check the Releases and Sprints

numbering with mapping to calendar dates

42 Fifth Major Release

Following is a description of features per Generic Enablers that will be supported in Release 5 of

FIWARE both in the backend and gateway parts

421 Backend

4211 Backend Device Management

o Addition of new IoT protocols by means of new dedicated IoT Agents Examples

OneM2M (inlcuding MCA northbound interface) amp Modbus

o Development of IoT Agents at the Gateway level Mainly to replace the previous

Protocol Adapater GE

o Deliver new SDKs for different hardware platforms Arduino Cludino Intel Edision

ThinkingThings Open RaspberryPI etc

o Enable new features such as Device Management IoT infrastructure management

(using NGSI entities) etc

o Migration of all IoT Agents to nodejs implementations

4212 Backend IoT Broker

o intelligent update request handling

o efficient and energy saving IoT subsystem invocation

o Enhance interface capabilities

o harmonize additional interface features towards NGSI v2 support

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 12

4213 Backend IoT Discovery

o Support geo-location discovery of entities

o evolve (semantic) linked-data platform API to 2nd version

o evolve NGSI API to 2nd version

o provide ontology for IoT entities

o provide a dataset generator for initial testing

o change store from object database to document store

FIWARE

GE Supported Features Epics under analysis

Backend

Device

Manage

ment

Release 51

FIWAREFeatureIoTIDASModularityHomog

eneousCommands

FIWAREFeatureIoTIDASModularityDevices

Timezone

FIWAREFeatureIoTIDASModularityDeviceL

ifeCicle

FIWAREFeatureIoTIDASModularityDeleteF

unctions

Release 52

FIWAREFeatureIoTIDASProtocolsOneM2M

Basic

FIWAREFeatureIoTIDASDevKitSDKIntelEdis

on

FIWAREFeatureIoTIDASDevKitSDKArduino

Release 53

FIWAREFeatureIoTIDASProtocolsnodejsMi

gration

FIWAREFeatureIoTIDASModularityNewGit

hubOrganization

FIWAREFeatureIoTIDASModularityImprov

eOperations

FIWAREEpicIoTIDASModula

rity

FIWAREEpicIoTIDASProtoc

ols

FIWAREEpicIoTIDASDevKit

FIWAREEpicIoTIDASGeoDes

cription

FIWAREEpicIoTIDASEdgeM

anagement

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 13

Release 54

FIWAREFeatureIoTIDASModularityIoTMan

agerAdvanced

FIWAREFeatureIoTIDASEdgeManagementI

oTInfrastructure

FIWAREFeatureIoTIDASGeoDescriptionPOI

s-Integration

Backend

IoT

Broker

Release 51

FIWAREFeatureIoTBackendIoTBrokerSmart

UpdateHandler

Release 52

FIWAREFeatureIoTBackendIoTBrokerHistor

yQueries

FIWAREFeatureIoTBackendIoTBrokerAdva

ncedQueries

Release 53

FIWAREFeatureIoTBackendIoTBrokerInterf

aceNGSIv2

Release 54

IoT

Discover

y

Release 51

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9GeoLocation

FIWAREFeatureIoTIoTDiscoveryInterfaceS

emanticRegApiV2

FIWAREFeatureIoTIoTDiscoveryRepository

DatasetGenerator

Release 52

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

FIWAREFeatureIoTIoTDiscoveryInterfaceN

FIWAREEpicIoTIoTDiscovery

Interface

FIWAREEpicIoTIoTDiscovery

Interoperability

FIWAREEpicIoTIoTDiscovery

Repository

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 14

gsiV2

Release 53

FIWAREFeatureIoTIoTDiscoveryInterfaceN

gsiV2

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

Release 54

FIWAREFeatureIoTIoTDiscoveryInterface

WebUI

422 Gateway

4221 IoT Data Edge Consolidation

The main effort in release 5 is to be compliant NGSI V2 and to improve the robustness of the broker and

the CEP

o the CEP will offer geofencing operations

o the broker will be compliant ngsi9

o the broker and the CEP will interface with other GE with NGSI V2

FIWAR

E GE Supported Features Epics under analysis

IoT

Data

Edge

Consol

idatio

Release 51

FIWAREFeatureIoTIotDataEdgeConsolidati

onLocalStoragepubsub

FIWAREEpicIoTIotDataEdgeCo

nsolidationLocalStorage

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 15

n FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2GeolocTimes

tamp

FIWAREFeatureIoTIotDataEdgeConsolidati

onBrokerFilterUpdateContext

FIWAREFeatureIoTIotDataEdgeConsolidati

onComplexEventProcessingComplexType

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSI9

Release 52

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2

Release 53

FIWAREFeatureIoTIotDataEdgeConsolidati

onManagerNgsiConfiguration

Release 54

FIWAREFeatureIoTDataEdge-

CepheusNGSI9Operations

FIWAREFeatureIoTDataEdge-

CepheusCEPNGSIConfiguration

FIWAREEpicIoTIotDataEdgeCo

nsolidationBroker

FIWAREEpicIoTIotDataEdgeCo

nsolidationCommonDataModel

FIWAREEpicIoTIotDataEdgeCo

nsolidationComplexEventProce

ssing

FIWAREEpicIoTIotDataEdgeCo

nsolidationManager

43 Future releases

The following features and epics correspond to features that are in the roadmap of the respective

Generic Enablers but are not going to be implemented as part of FIWARE project activities Some of

them may continue under the FIWARE Community activities some others will not

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 16

You can check out the previous releases of this FIWARE chapter on Roadmap of Internet of Things (IoT)

Services(previous releases)

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 17

5 Backend Device Management GE

51 IDAS Modularity Epic

Name Refactoring

IoT Agents

Chapter IoT

Goal Evolution of the architecture and implementation according to developers

feedback

Description To evolve from a C++ monolithic architecture (extensible via C++ plugins) towards

a modular design where each module (IoT Agent) focusses on a reduce set of IoT

Southbound Protocols and is written in any language This will significantly reduce

the complexity of installation and operation of this component

Rationale Lighter architecture and easier installation operation and extensibility The idea is

to provide modules (IoT Agents) for one or a reduced number of IoT southbound

protocols for easier installation and improved operations and scalability

52 IDAS Protocols Epic

Name New

Protocols

- IoT

Agents

Chapter

IoT

Goal Evolution of the architecture and implementation according to industry trends

Description Besides providing backwards compatibility new southbound technologies and

protocols need to be adopted as long as there are new proposals comming from

Industrial alliances and also open and propietary standards that are relavnt

enough to be adopted

Rationale To make FIWARE IoT competitive regarding the latest emerging trends and

industrial propositions The idea behind the IoT agents is to provide such an easy

extensibility and IoT Agents skeletons are provided to developers (in C++ and

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 18

nodejs) so they can also add new protocols if needed

53 IDAS DevKit Epic

Name FIGWAY

Testing

Tools

Chapter

IoT

Goal Provide a set of testing and training tools regarding FIWARE IoT

Description To provide means for experimenting with different kinds of virtual or pyhical

sensor and actuators Particularly virtual sensors emnable simulations and Apps

developmen t before installing devices in place allowing issues antcipation and

improving time to market of IoT projects

Rationale Easy learning testing and training with FIWARE IoT by providing software tools to

be installed in gateways andor laptops desktop PCs etc to perform simulations

54 IDAS GeoDescription Epic

Name Geographical

Description

Chapter IoT

Goal Identify standard methods to add geolocation data to IoT devices so that graphical

representation can be improved

Description Identify standard methods and protocols to add geolocation data to IoT devices so

that graphical representation can be improved Therea re many available options

but the one that is being worked out in the data chapter for the 2D and 3D

interfaces has been finally selected

Rationale Improve graphical presentation of IoT by providing a standar way to add location

metadata to the devices themselves The specification guarantees the

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 19

compatibility with the FIWARE 2D and 3D user interfaces

55 IDAS EdgeManagement Epic

Name IoT Edge

Management

Chapter IoT

Goal Provide an easy way to configure underlaying southbound infrastructure

(gateways networks connectivity security etc)

Description To make the life of IoT providers easier with platform tools So far IDAS was

mainly focussed on translating southbound IoT protocols intro NGSI but this EPIC

will cover the easy deployment and operations of Edge related elements

(gateways connectivity etc)

Rationale The idea behind this EPIC is to make IoT deployments easier and consider the

feedback provided by developers and integrators on this specific area

56 Modularity ndash Homogeneous Commands Feature

Name BE

DeviceManagement

Homogeneous

Commands

Chapter

IoT

Goal Implement the new specs for commands (real-time andor polling) for all IoT

Agents

Description This feature aligns all IoT Agents regarding commands delivery The idea is to

have a common specification for all the ADMIN API and Commands API of the

different IoT Agents

Rationale Provide a common ADMIN API and Commands API for all IoT Agents The

ADMIN API is a REST HTTP API that is similar to the IoT Manager one and it

enables Admins to provision devices services subservices and other

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 20

configurable elements

57 Modularity ndash Devices Timezone Feature

Name BE

DeviceManagement

Device Timezone

Functions

Chapter

IoT

Goal Implement a Timezone function (devices not in GMT) for all IoT Agents

Description This feature aligns all IoT Agents to be able to configure the timezone of

devices The idea is to have a common specification for all the ADMIN API of

the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST

HTTP API that is similar to the IoT Manager one and it enables Admins to

provision devices services subservices and other configurable elements

58 Modularity ndash Device Life Cicle Feature

Name BE

DeviceManagement

Device Life Cicle

Functions

Chapter

IoT

Goal Implement Device Life Cicle functions (enabledisable in addition to

provisiondelete) for all IoT Agents

Description This feature aligns all IoT Agents to be able to manage devices and other

configurable elements (for instance configure a service to accept only pre-

provisioned devices) The idea is to have a common specification for all the

ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 8: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 8

2 FIWARE Technical Roadmap

FIWAREs technical roadmap brings information about what the different major releases of FIWARE will

bring and when they will be available on FIWARE Lab For each of the FIWARE chapters and for every

generic enabler the list of features available for the particular release is linked within the following

pages You can explore which release number the particular features are currently scheduled for and

contact the affiliated responsible persons in charge if you need more details

The first version of the FIWARE platform was made available on the FIWARE Testbed during 3Q2012 for

experiments by the use case projects within the FI-PPP program The overall goal for this first Release

was to provide a sufficiently complete set of FIWARE GEs which Use Case Projects selected in the first

phase of the FI-PPP program could test and use in their proof of concepts The second release of FIWARE

is focused on integration (both inside and across chapters) as well as evolution of FIWARE GEs based on

feedback from target Users (both Use Case Projects selected in the first phase of the FI-PPP or other

stakeholders like currenttarget customers of FIWARE partners) The third release is focused on

consolidation of the platform and packaging

The fourth and fifth releases will be delivered by a new set of partners (many of them already present in

releases 1 2 and 3) and will bring a reorganization of the map of GEs These GEs will continue building

the core platform ensuring that the results are open and royalty free

Once the development of a given minor release of FIWARE is finished it can be made available on

FIWARE Lab typically by the end of the following month Updates of all FIWARE GEs on FIWARE Lab will

be planned after each major release completion Nevertheless updates of FIWARE Lab may be decided

on a more frequent basis at FIWARE GE level ie the following month after completion of some Sprint

Please check the Releases and Sprints numbering with mapping to calendar dates for further

information

FIWAREs Technical Roadmap is broken into 7 partial roadmaps one per FIWARE Technical Chapter

Roadmap of Cloud Hosting

Roadmap of DataContext Management

Roadmap of Internet of Things (IoT) Services

Roadmap of ApplicationsServices Ecosystem and Delivery Framework

Roadmap of Security

Roadmap of Advanced middleware Interface to Networks and Robotics

Roadmap of Advanced Web-based UI

The Developers Community and Tools chapter has changed their focus and they do not produce GEs as

such anymore We keep their past roadmap as it was at the end of 2014 for future reference

Roadmap of Developers Community and Tools

Important Note it is important to mention that most (if not all) of the Generic Enabler implementations

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 9

are based on existing baseline assets (open source or proprietary) actively developed and promoted by

the corresponding companies Each company has done internal analysis of requirements and priorities

for each of the technologies based on their business needs and the needs of their customers The goal

of FIWARE is to develop these assets even further to integrate them together to form a coherent

platform and to offer them to the FI-PPP ecosystem for the benefit of the community This roadmap

reflects this approach

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 10

3 Releases and Sprints numbering with mapping to

calendar dates The list of Releases and Sprints together with the time frame of each one of them is depicted in the

following table

Versions

Oct

201

4

No

v

201

4

De

c

201

4

Jan

201

5

Feb

201

5

Ma

r

201

5

Apr

201

5

Ma

y

201

5

Jun

201

5

Jul

201

5

Au

g

201

5

Sep

201

5

Oct

201

5

No

v

201

5

De

c

201

5

Jan

201

6

Feb

201

6

Ma

r

201

6

Apr

201

6

Ma

y

201

6

Jun

201

6

Jul

201

6

Au

g

201

6

Sep

201

6

FIWARE(Clo

sed) Month

Number

M4

2

M4

3

M4

4

FIWARE

Continuatio

n (ongoing)

Month

Number

M2 M3 M4 M5 M6 M7 M8 M9 M1

0

M1

1

M1

2

M1

3

M1

4

M1

5

M1

6

M1

7

M1

8

M1

9

M2

0

M2

1

M2

2

M2

3

M2

4

M2

5

First Major

Release

Second

Major

Release

Third Major

Release

Fourth

Major

Release

41

1

41

2

41

3

42

1

42

2

42

3

43

1

43

2

43

3

44

1

44

2

44

3

Fifth Major

Release

51

1

51

2

51

3

52

1

52

2

52

3

53

1

53

2

53

3

54

1

54

2

54

3

PLEASE NOTE that software associated to Minor Releases may be made available on the FIWARE

Testbed and FIWARE Lab after completing that Minor Release typically by the end of the following

month A revised version of the documentation accompanying software delivered after closing a Minor

Release is also typically delivered by end of the following month

Updates of all FIWARE GEs on the FIWARE Testbed will be planned after each Major Release completion

Besides updates of the FIWARE Testbed may be decided on a more frequent basis at FIWARE GE level

ie the following month after completion of some Sprint

As explained in FIWARE Agile Development Methodology the Releases and Sprints are referred to as

FIWAREReleasexy

FIWARESprintxyz

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 11

4 Roadmap of Internet of Things (IoT) Services

41 Introduction

The Internet of Things Service Enablement chapter in FIWARE provides key assets enabling access to IoT

resources

You can learn more about the IoT Chapter by reading the FIWARE Architecture and Open Specifications

Following is a description of the Technical Roadmap planned for the chapter which will be developed

through subsequent Releases of the FIWARE Platform Please also check the Releases and Sprints

numbering with mapping to calendar dates

42 Fifth Major Release

Following is a description of features per Generic Enablers that will be supported in Release 5 of

FIWARE both in the backend and gateway parts

421 Backend

4211 Backend Device Management

o Addition of new IoT protocols by means of new dedicated IoT Agents Examples

OneM2M (inlcuding MCA northbound interface) amp Modbus

o Development of IoT Agents at the Gateway level Mainly to replace the previous

Protocol Adapater GE

o Deliver new SDKs for different hardware platforms Arduino Cludino Intel Edision

ThinkingThings Open RaspberryPI etc

o Enable new features such as Device Management IoT infrastructure management

(using NGSI entities) etc

o Migration of all IoT Agents to nodejs implementations

4212 Backend IoT Broker

o intelligent update request handling

o efficient and energy saving IoT subsystem invocation

o Enhance interface capabilities

o harmonize additional interface features towards NGSI v2 support

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 12

4213 Backend IoT Discovery

o Support geo-location discovery of entities

o evolve (semantic) linked-data platform API to 2nd version

o evolve NGSI API to 2nd version

o provide ontology for IoT entities

o provide a dataset generator for initial testing

o change store from object database to document store

FIWARE

GE Supported Features Epics under analysis

Backend

Device

Manage

ment

Release 51

FIWAREFeatureIoTIDASModularityHomog

eneousCommands

FIWAREFeatureIoTIDASModularityDevices

Timezone

FIWAREFeatureIoTIDASModularityDeviceL

ifeCicle

FIWAREFeatureIoTIDASModularityDeleteF

unctions

Release 52

FIWAREFeatureIoTIDASProtocolsOneM2M

Basic

FIWAREFeatureIoTIDASDevKitSDKIntelEdis

on

FIWAREFeatureIoTIDASDevKitSDKArduino

Release 53

FIWAREFeatureIoTIDASProtocolsnodejsMi

gration

FIWAREFeatureIoTIDASModularityNewGit

hubOrganization

FIWAREFeatureIoTIDASModularityImprov

eOperations

FIWAREEpicIoTIDASModula

rity

FIWAREEpicIoTIDASProtoc

ols

FIWAREEpicIoTIDASDevKit

FIWAREEpicIoTIDASGeoDes

cription

FIWAREEpicIoTIDASEdgeM

anagement

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 13

Release 54

FIWAREFeatureIoTIDASModularityIoTMan

agerAdvanced

FIWAREFeatureIoTIDASEdgeManagementI

oTInfrastructure

FIWAREFeatureIoTIDASGeoDescriptionPOI

s-Integration

Backend

IoT

Broker

Release 51

FIWAREFeatureIoTBackendIoTBrokerSmart

UpdateHandler

Release 52

FIWAREFeatureIoTBackendIoTBrokerHistor

yQueries

FIWAREFeatureIoTBackendIoTBrokerAdva

ncedQueries

Release 53

FIWAREFeatureIoTBackendIoTBrokerInterf

aceNGSIv2

Release 54

IoT

Discover

y

Release 51

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9GeoLocation

FIWAREFeatureIoTIoTDiscoveryInterfaceS

emanticRegApiV2

FIWAREFeatureIoTIoTDiscoveryRepository

DatasetGenerator

Release 52

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

FIWAREFeatureIoTIoTDiscoveryInterfaceN

FIWAREEpicIoTIoTDiscovery

Interface

FIWAREEpicIoTIoTDiscovery

Interoperability

FIWAREEpicIoTIoTDiscovery

Repository

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 14

gsiV2

Release 53

FIWAREFeatureIoTIoTDiscoveryInterfaceN

gsiV2

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

Release 54

FIWAREFeatureIoTIoTDiscoveryInterface

WebUI

422 Gateway

4221 IoT Data Edge Consolidation

The main effort in release 5 is to be compliant NGSI V2 and to improve the robustness of the broker and

the CEP

o the CEP will offer geofencing operations

o the broker will be compliant ngsi9

o the broker and the CEP will interface with other GE with NGSI V2

FIWAR

E GE Supported Features Epics under analysis

IoT

Data

Edge

Consol

idatio

Release 51

FIWAREFeatureIoTIotDataEdgeConsolidati

onLocalStoragepubsub

FIWAREEpicIoTIotDataEdgeCo

nsolidationLocalStorage

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 15

n FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2GeolocTimes

tamp

FIWAREFeatureIoTIotDataEdgeConsolidati

onBrokerFilterUpdateContext

FIWAREFeatureIoTIotDataEdgeConsolidati

onComplexEventProcessingComplexType

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSI9

Release 52

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2

Release 53

FIWAREFeatureIoTIotDataEdgeConsolidati

onManagerNgsiConfiguration

Release 54

FIWAREFeatureIoTDataEdge-

CepheusNGSI9Operations

FIWAREFeatureIoTDataEdge-

CepheusCEPNGSIConfiguration

FIWAREEpicIoTIotDataEdgeCo

nsolidationBroker

FIWAREEpicIoTIotDataEdgeCo

nsolidationCommonDataModel

FIWAREEpicIoTIotDataEdgeCo

nsolidationComplexEventProce

ssing

FIWAREEpicIoTIotDataEdgeCo

nsolidationManager

43 Future releases

The following features and epics correspond to features that are in the roadmap of the respective

Generic Enablers but are not going to be implemented as part of FIWARE project activities Some of

them may continue under the FIWARE Community activities some others will not

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 16

You can check out the previous releases of this FIWARE chapter on Roadmap of Internet of Things (IoT)

Services(previous releases)

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 17

5 Backend Device Management GE

51 IDAS Modularity Epic

Name Refactoring

IoT Agents

Chapter IoT

Goal Evolution of the architecture and implementation according to developers

feedback

Description To evolve from a C++ monolithic architecture (extensible via C++ plugins) towards

a modular design where each module (IoT Agent) focusses on a reduce set of IoT

Southbound Protocols and is written in any language This will significantly reduce

the complexity of installation and operation of this component

Rationale Lighter architecture and easier installation operation and extensibility The idea is

to provide modules (IoT Agents) for one or a reduced number of IoT southbound

protocols for easier installation and improved operations and scalability

52 IDAS Protocols Epic

Name New

Protocols

- IoT

Agents

Chapter

IoT

Goal Evolution of the architecture and implementation according to industry trends

Description Besides providing backwards compatibility new southbound technologies and

protocols need to be adopted as long as there are new proposals comming from

Industrial alliances and also open and propietary standards that are relavnt

enough to be adopted

Rationale To make FIWARE IoT competitive regarding the latest emerging trends and

industrial propositions The idea behind the IoT agents is to provide such an easy

extensibility and IoT Agents skeletons are provided to developers (in C++ and

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 18

nodejs) so they can also add new protocols if needed

53 IDAS DevKit Epic

Name FIGWAY

Testing

Tools

Chapter

IoT

Goal Provide a set of testing and training tools regarding FIWARE IoT

Description To provide means for experimenting with different kinds of virtual or pyhical

sensor and actuators Particularly virtual sensors emnable simulations and Apps

developmen t before installing devices in place allowing issues antcipation and

improving time to market of IoT projects

Rationale Easy learning testing and training with FIWARE IoT by providing software tools to

be installed in gateways andor laptops desktop PCs etc to perform simulations

54 IDAS GeoDescription Epic

Name Geographical

Description

Chapter IoT

Goal Identify standard methods to add geolocation data to IoT devices so that graphical

representation can be improved

Description Identify standard methods and protocols to add geolocation data to IoT devices so

that graphical representation can be improved Therea re many available options

but the one that is being worked out in the data chapter for the 2D and 3D

interfaces has been finally selected

Rationale Improve graphical presentation of IoT by providing a standar way to add location

metadata to the devices themselves The specification guarantees the

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 19

compatibility with the FIWARE 2D and 3D user interfaces

55 IDAS EdgeManagement Epic

Name IoT Edge

Management

Chapter IoT

Goal Provide an easy way to configure underlaying southbound infrastructure

(gateways networks connectivity security etc)

Description To make the life of IoT providers easier with platform tools So far IDAS was

mainly focussed on translating southbound IoT protocols intro NGSI but this EPIC

will cover the easy deployment and operations of Edge related elements

(gateways connectivity etc)

Rationale The idea behind this EPIC is to make IoT deployments easier and consider the

feedback provided by developers and integrators on this specific area

56 Modularity ndash Homogeneous Commands Feature

Name BE

DeviceManagement

Homogeneous

Commands

Chapter

IoT

Goal Implement the new specs for commands (real-time andor polling) for all IoT

Agents

Description This feature aligns all IoT Agents regarding commands delivery The idea is to

have a common specification for all the ADMIN API and Commands API of the

different IoT Agents

Rationale Provide a common ADMIN API and Commands API for all IoT Agents The

ADMIN API is a REST HTTP API that is similar to the IoT Manager one and it

enables Admins to provision devices services subservices and other

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 20

configurable elements

57 Modularity ndash Devices Timezone Feature

Name BE

DeviceManagement

Device Timezone

Functions

Chapter

IoT

Goal Implement a Timezone function (devices not in GMT) for all IoT Agents

Description This feature aligns all IoT Agents to be able to configure the timezone of

devices The idea is to have a common specification for all the ADMIN API of

the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST

HTTP API that is similar to the IoT Manager one and it enables Admins to

provision devices services subservices and other configurable elements

58 Modularity ndash Device Life Cicle Feature

Name BE

DeviceManagement

Device Life Cicle

Functions

Chapter

IoT

Goal Implement Device Life Cicle functions (enabledisable in addition to

provisiondelete) for all IoT Agents

Description This feature aligns all IoT Agents to be able to manage devices and other

configurable elements (for instance configure a service to accept only pre-

provisioned devices) The idea is to have a common specification for all the

ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 9: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 9

are based on existing baseline assets (open source or proprietary) actively developed and promoted by

the corresponding companies Each company has done internal analysis of requirements and priorities

for each of the technologies based on their business needs and the needs of their customers The goal

of FIWARE is to develop these assets even further to integrate them together to form a coherent

platform and to offer them to the FI-PPP ecosystem for the benefit of the community This roadmap

reflects this approach

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 10

3 Releases and Sprints numbering with mapping to

calendar dates The list of Releases and Sprints together with the time frame of each one of them is depicted in the

following table

Versions

Oct

201

4

No

v

201

4

De

c

201

4

Jan

201

5

Feb

201

5

Ma

r

201

5

Apr

201

5

Ma

y

201

5

Jun

201

5

Jul

201

5

Au

g

201

5

Sep

201

5

Oct

201

5

No

v

201

5

De

c

201

5

Jan

201

6

Feb

201

6

Ma

r

201

6

Apr

201

6

Ma

y

201

6

Jun

201

6

Jul

201

6

Au

g

201

6

Sep

201

6

FIWARE(Clo

sed) Month

Number

M4

2

M4

3

M4

4

FIWARE

Continuatio

n (ongoing)

Month

Number

M2 M3 M4 M5 M6 M7 M8 M9 M1

0

M1

1

M1

2

M1

3

M1

4

M1

5

M1

6

M1

7

M1

8

M1

9

M2

0

M2

1

M2

2

M2

3

M2

4

M2

5

First Major

Release

Second

Major

Release

Third Major

Release

Fourth

Major

Release

41

1

41

2

41

3

42

1

42

2

42

3

43

1

43

2

43

3

44

1

44

2

44

3

Fifth Major

Release

51

1

51

2

51

3

52

1

52

2

52

3

53

1

53

2

53

3

54

1

54

2

54

3

PLEASE NOTE that software associated to Minor Releases may be made available on the FIWARE

Testbed and FIWARE Lab after completing that Minor Release typically by the end of the following

month A revised version of the documentation accompanying software delivered after closing a Minor

Release is also typically delivered by end of the following month

Updates of all FIWARE GEs on the FIWARE Testbed will be planned after each Major Release completion

Besides updates of the FIWARE Testbed may be decided on a more frequent basis at FIWARE GE level

ie the following month after completion of some Sprint

As explained in FIWARE Agile Development Methodology the Releases and Sprints are referred to as

FIWAREReleasexy

FIWARESprintxyz

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 11

4 Roadmap of Internet of Things (IoT) Services

41 Introduction

The Internet of Things Service Enablement chapter in FIWARE provides key assets enabling access to IoT

resources

You can learn more about the IoT Chapter by reading the FIWARE Architecture and Open Specifications

Following is a description of the Technical Roadmap planned for the chapter which will be developed

through subsequent Releases of the FIWARE Platform Please also check the Releases and Sprints

numbering with mapping to calendar dates

42 Fifth Major Release

Following is a description of features per Generic Enablers that will be supported in Release 5 of

FIWARE both in the backend and gateway parts

421 Backend

4211 Backend Device Management

o Addition of new IoT protocols by means of new dedicated IoT Agents Examples

OneM2M (inlcuding MCA northbound interface) amp Modbus

o Development of IoT Agents at the Gateway level Mainly to replace the previous

Protocol Adapater GE

o Deliver new SDKs for different hardware platforms Arduino Cludino Intel Edision

ThinkingThings Open RaspberryPI etc

o Enable new features such as Device Management IoT infrastructure management

(using NGSI entities) etc

o Migration of all IoT Agents to nodejs implementations

4212 Backend IoT Broker

o intelligent update request handling

o efficient and energy saving IoT subsystem invocation

o Enhance interface capabilities

o harmonize additional interface features towards NGSI v2 support

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 12

4213 Backend IoT Discovery

o Support geo-location discovery of entities

o evolve (semantic) linked-data platform API to 2nd version

o evolve NGSI API to 2nd version

o provide ontology for IoT entities

o provide a dataset generator for initial testing

o change store from object database to document store

FIWARE

GE Supported Features Epics under analysis

Backend

Device

Manage

ment

Release 51

FIWAREFeatureIoTIDASModularityHomog

eneousCommands

FIWAREFeatureIoTIDASModularityDevices

Timezone

FIWAREFeatureIoTIDASModularityDeviceL

ifeCicle

FIWAREFeatureIoTIDASModularityDeleteF

unctions

Release 52

FIWAREFeatureIoTIDASProtocolsOneM2M

Basic

FIWAREFeatureIoTIDASDevKitSDKIntelEdis

on

FIWAREFeatureIoTIDASDevKitSDKArduino

Release 53

FIWAREFeatureIoTIDASProtocolsnodejsMi

gration

FIWAREFeatureIoTIDASModularityNewGit

hubOrganization

FIWAREFeatureIoTIDASModularityImprov

eOperations

FIWAREEpicIoTIDASModula

rity

FIWAREEpicIoTIDASProtoc

ols

FIWAREEpicIoTIDASDevKit

FIWAREEpicIoTIDASGeoDes

cription

FIWAREEpicIoTIDASEdgeM

anagement

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 13

Release 54

FIWAREFeatureIoTIDASModularityIoTMan

agerAdvanced

FIWAREFeatureIoTIDASEdgeManagementI

oTInfrastructure

FIWAREFeatureIoTIDASGeoDescriptionPOI

s-Integration

Backend

IoT

Broker

Release 51

FIWAREFeatureIoTBackendIoTBrokerSmart

UpdateHandler

Release 52

FIWAREFeatureIoTBackendIoTBrokerHistor

yQueries

FIWAREFeatureIoTBackendIoTBrokerAdva

ncedQueries

Release 53

FIWAREFeatureIoTBackendIoTBrokerInterf

aceNGSIv2

Release 54

IoT

Discover

y

Release 51

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9GeoLocation

FIWAREFeatureIoTIoTDiscoveryInterfaceS

emanticRegApiV2

FIWAREFeatureIoTIoTDiscoveryRepository

DatasetGenerator

Release 52

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

FIWAREFeatureIoTIoTDiscoveryInterfaceN

FIWAREEpicIoTIoTDiscovery

Interface

FIWAREEpicIoTIoTDiscovery

Interoperability

FIWAREEpicIoTIoTDiscovery

Repository

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 14

gsiV2

Release 53

FIWAREFeatureIoTIoTDiscoveryInterfaceN

gsiV2

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

Release 54

FIWAREFeatureIoTIoTDiscoveryInterface

WebUI

422 Gateway

4221 IoT Data Edge Consolidation

The main effort in release 5 is to be compliant NGSI V2 and to improve the robustness of the broker and

the CEP

o the CEP will offer geofencing operations

o the broker will be compliant ngsi9

o the broker and the CEP will interface with other GE with NGSI V2

FIWAR

E GE Supported Features Epics under analysis

IoT

Data

Edge

Consol

idatio

Release 51

FIWAREFeatureIoTIotDataEdgeConsolidati

onLocalStoragepubsub

FIWAREEpicIoTIotDataEdgeCo

nsolidationLocalStorage

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 15

n FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2GeolocTimes

tamp

FIWAREFeatureIoTIotDataEdgeConsolidati

onBrokerFilterUpdateContext

FIWAREFeatureIoTIotDataEdgeConsolidati

onComplexEventProcessingComplexType

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSI9

Release 52

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2

Release 53

FIWAREFeatureIoTIotDataEdgeConsolidati

onManagerNgsiConfiguration

Release 54

FIWAREFeatureIoTDataEdge-

CepheusNGSI9Operations

FIWAREFeatureIoTDataEdge-

CepheusCEPNGSIConfiguration

FIWAREEpicIoTIotDataEdgeCo

nsolidationBroker

FIWAREEpicIoTIotDataEdgeCo

nsolidationCommonDataModel

FIWAREEpicIoTIotDataEdgeCo

nsolidationComplexEventProce

ssing

FIWAREEpicIoTIotDataEdgeCo

nsolidationManager

43 Future releases

The following features and epics correspond to features that are in the roadmap of the respective

Generic Enablers but are not going to be implemented as part of FIWARE project activities Some of

them may continue under the FIWARE Community activities some others will not

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 16

You can check out the previous releases of this FIWARE chapter on Roadmap of Internet of Things (IoT)

Services(previous releases)

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 17

5 Backend Device Management GE

51 IDAS Modularity Epic

Name Refactoring

IoT Agents

Chapter IoT

Goal Evolution of the architecture and implementation according to developers

feedback

Description To evolve from a C++ monolithic architecture (extensible via C++ plugins) towards

a modular design where each module (IoT Agent) focusses on a reduce set of IoT

Southbound Protocols and is written in any language This will significantly reduce

the complexity of installation and operation of this component

Rationale Lighter architecture and easier installation operation and extensibility The idea is

to provide modules (IoT Agents) for one or a reduced number of IoT southbound

protocols for easier installation and improved operations and scalability

52 IDAS Protocols Epic

Name New

Protocols

- IoT

Agents

Chapter

IoT

Goal Evolution of the architecture and implementation according to industry trends

Description Besides providing backwards compatibility new southbound technologies and

protocols need to be adopted as long as there are new proposals comming from

Industrial alliances and also open and propietary standards that are relavnt

enough to be adopted

Rationale To make FIWARE IoT competitive regarding the latest emerging trends and

industrial propositions The idea behind the IoT agents is to provide such an easy

extensibility and IoT Agents skeletons are provided to developers (in C++ and

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 18

nodejs) so they can also add new protocols if needed

53 IDAS DevKit Epic

Name FIGWAY

Testing

Tools

Chapter

IoT

Goal Provide a set of testing and training tools regarding FIWARE IoT

Description To provide means for experimenting with different kinds of virtual or pyhical

sensor and actuators Particularly virtual sensors emnable simulations and Apps

developmen t before installing devices in place allowing issues antcipation and

improving time to market of IoT projects

Rationale Easy learning testing and training with FIWARE IoT by providing software tools to

be installed in gateways andor laptops desktop PCs etc to perform simulations

54 IDAS GeoDescription Epic

Name Geographical

Description

Chapter IoT

Goal Identify standard methods to add geolocation data to IoT devices so that graphical

representation can be improved

Description Identify standard methods and protocols to add geolocation data to IoT devices so

that graphical representation can be improved Therea re many available options

but the one that is being worked out in the data chapter for the 2D and 3D

interfaces has been finally selected

Rationale Improve graphical presentation of IoT by providing a standar way to add location

metadata to the devices themselves The specification guarantees the

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 19

compatibility with the FIWARE 2D and 3D user interfaces

55 IDAS EdgeManagement Epic

Name IoT Edge

Management

Chapter IoT

Goal Provide an easy way to configure underlaying southbound infrastructure

(gateways networks connectivity security etc)

Description To make the life of IoT providers easier with platform tools So far IDAS was

mainly focussed on translating southbound IoT protocols intro NGSI but this EPIC

will cover the easy deployment and operations of Edge related elements

(gateways connectivity etc)

Rationale The idea behind this EPIC is to make IoT deployments easier and consider the

feedback provided by developers and integrators on this specific area

56 Modularity ndash Homogeneous Commands Feature

Name BE

DeviceManagement

Homogeneous

Commands

Chapter

IoT

Goal Implement the new specs for commands (real-time andor polling) for all IoT

Agents

Description This feature aligns all IoT Agents regarding commands delivery The idea is to

have a common specification for all the ADMIN API and Commands API of the

different IoT Agents

Rationale Provide a common ADMIN API and Commands API for all IoT Agents The

ADMIN API is a REST HTTP API that is similar to the IoT Manager one and it

enables Admins to provision devices services subservices and other

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 20

configurable elements

57 Modularity ndash Devices Timezone Feature

Name BE

DeviceManagement

Device Timezone

Functions

Chapter

IoT

Goal Implement a Timezone function (devices not in GMT) for all IoT Agents

Description This feature aligns all IoT Agents to be able to configure the timezone of

devices The idea is to have a common specification for all the ADMIN API of

the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST

HTTP API that is similar to the IoT Manager one and it enables Admins to

provision devices services subservices and other configurable elements

58 Modularity ndash Device Life Cicle Feature

Name BE

DeviceManagement

Device Life Cicle

Functions

Chapter

IoT

Goal Implement Device Life Cicle functions (enabledisable in addition to

provisiondelete) for all IoT Agents

Description This feature aligns all IoT Agents to be able to manage devices and other

configurable elements (for instance configure a service to accept only pre-

provisioned devices) The idea is to have a common specification for all the

ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 10: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 10

3 Releases and Sprints numbering with mapping to

calendar dates The list of Releases and Sprints together with the time frame of each one of them is depicted in the

following table

Versions

Oct

201

4

No

v

201

4

De

c

201

4

Jan

201

5

Feb

201

5

Ma

r

201

5

Apr

201

5

Ma

y

201

5

Jun

201

5

Jul

201

5

Au

g

201

5

Sep

201

5

Oct

201

5

No

v

201

5

De

c

201

5

Jan

201

6

Feb

201

6

Ma

r

201

6

Apr

201

6

Ma

y

201

6

Jun

201

6

Jul

201

6

Au

g

201

6

Sep

201

6

FIWARE(Clo

sed) Month

Number

M4

2

M4

3

M4

4

FIWARE

Continuatio

n (ongoing)

Month

Number

M2 M3 M4 M5 M6 M7 M8 M9 M1

0

M1

1

M1

2

M1

3

M1

4

M1

5

M1

6

M1

7

M1

8

M1

9

M2

0

M2

1

M2

2

M2

3

M2

4

M2

5

First Major

Release

Second

Major

Release

Third Major

Release

Fourth

Major

Release

41

1

41

2

41

3

42

1

42

2

42

3

43

1

43

2

43

3

44

1

44

2

44

3

Fifth Major

Release

51

1

51

2

51

3

52

1

52

2

52

3

53

1

53

2

53

3

54

1

54

2

54

3

PLEASE NOTE that software associated to Minor Releases may be made available on the FIWARE

Testbed and FIWARE Lab after completing that Minor Release typically by the end of the following

month A revised version of the documentation accompanying software delivered after closing a Minor

Release is also typically delivered by end of the following month

Updates of all FIWARE GEs on the FIWARE Testbed will be planned after each Major Release completion

Besides updates of the FIWARE Testbed may be decided on a more frequent basis at FIWARE GE level

ie the following month after completion of some Sprint

As explained in FIWARE Agile Development Methodology the Releases and Sprints are referred to as

FIWAREReleasexy

FIWARESprintxyz

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 11

4 Roadmap of Internet of Things (IoT) Services

41 Introduction

The Internet of Things Service Enablement chapter in FIWARE provides key assets enabling access to IoT

resources

You can learn more about the IoT Chapter by reading the FIWARE Architecture and Open Specifications

Following is a description of the Technical Roadmap planned for the chapter which will be developed

through subsequent Releases of the FIWARE Platform Please also check the Releases and Sprints

numbering with mapping to calendar dates

42 Fifth Major Release

Following is a description of features per Generic Enablers that will be supported in Release 5 of

FIWARE both in the backend and gateway parts

421 Backend

4211 Backend Device Management

o Addition of new IoT protocols by means of new dedicated IoT Agents Examples

OneM2M (inlcuding MCA northbound interface) amp Modbus

o Development of IoT Agents at the Gateway level Mainly to replace the previous

Protocol Adapater GE

o Deliver new SDKs for different hardware platforms Arduino Cludino Intel Edision

ThinkingThings Open RaspberryPI etc

o Enable new features such as Device Management IoT infrastructure management

(using NGSI entities) etc

o Migration of all IoT Agents to nodejs implementations

4212 Backend IoT Broker

o intelligent update request handling

o efficient and energy saving IoT subsystem invocation

o Enhance interface capabilities

o harmonize additional interface features towards NGSI v2 support

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 12

4213 Backend IoT Discovery

o Support geo-location discovery of entities

o evolve (semantic) linked-data platform API to 2nd version

o evolve NGSI API to 2nd version

o provide ontology for IoT entities

o provide a dataset generator for initial testing

o change store from object database to document store

FIWARE

GE Supported Features Epics under analysis

Backend

Device

Manage

ment

Release 51

FIWAREFeatureIoTIDASModularityHomog

eneousCommands

FIWAREFeatureIoTIDASModularityDevices

Timezone

FIWAREFeatureIoTIDASModularityDeviceL

ifeCicle

FIWAREFeatureIoTIDASModularityDeleteF

unctions

Release 52

FIWAREFeatureIoTIDASProtocolsOneM2M

Basic

FIWAREFeatureIoTIDASDevKitSDKIntelEdis

on

FIWAREFeatureIoTIDASDevKitSDKArduino

Release 53

FIWAREFeatureIoTIDASProtocolsnodejsMi

gration

FIWAREFeatureIoTIDASModularityNewGit

hubOrganization

FIWAREFeatureIoTIDASModularityImprov

eOperations

FIWAREEpicIoTIDASModula

rity

FIWAREEpicIoTIDASProtoc

ols

FIWAREEpicIoTIDASDevKit

FIWAREEpicIoTIDASGeoDes

cription

FIWAREEpicIoTIDASEdgeM

anagement

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 13

Release 54

FIWAREFeatureIoTIDASModularityIoTMan

agerAdvanced

FIWAREFeatureIoTIDASEdgeManagementI

oTInfrastructure

FIWAREFeatureIoTIDASGeoDescriptionPOI

s-Integration

Backend

IoT

Broker

Release 51

FIWAREFeatureIoTBackendIoTBrokerSmart

UpdateHandler

Release 52

FIWAREFeatureIoTBackendIoTBrokerHistor

yQueries

FIWAREFeatureIoTBackendIoTBrokerAdva

ncedQueries

Release 53

FIWAREFeatureIoTBackendIoTBrokerInterf

aceNGSIv2

Release 54

IoT

Discover

y

Release 51

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9GeoLocation

FIWAREFeatureIoTIoTDiscoveryInterfaceS

emanticRegApiV2

FIWAREFeatureIoTIoTDiscoveryRepository

DatasetGenerator

Release 52

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

FIWAREFeatureIoTIoTDiscoveryInterfaceN

FIWAREEpicIoTIoTDiscovery

Interface

FIWAREEpicIoTIoTDiscovery

Interoperability

FIWAREEpicIoTIoTDiscovery

Repository

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 14

gsiV2

Release 53

FIWAREFeatureIoTIoTDiscoveryInterfaceN

gsiV2

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

Release 54

FIWAREFeatureIoTIoTDiscoveryInterface

WebUI

422 Gateway

4221 IoT Data Edge Consolidation

The main effort in release 5 is to be compliant NGSI V2 and to improve the robustness of the broker and

the CEP

o the CEP will offer geofencing operations

o the broker will be compliant ngsi9

o the broker and the CEP will interface with other GE with NGSI V2

FIWAR

E GE Supported Features Epics under analysis

IoT

Data

Edge

Consol

idatio

Release 51

FIWAREFeatureIoTIotDataEdgeConsolidati

onLocalStoragepubsub

FIWAREEpicIoTIotDataEdgeCo

nsolidationLocalStorage

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 15

n FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2GeolocTimes

tamp

FIWAREFeatureIoTIotDataEdgeConsolidati

onBrokerFilterUpdateContext

FIWAREFeatureIoTIotDataEdgeConsolidati

onComplexEventProcessingComplexType

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSI9

Release 52

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2

Release 53

FIWAREFeatureIoTIotDataEdgeConsolidati

onManagerNgsiConfiguration

Release 54

FIWAREFeatureIoTDataEdge-

CepheusNGSI9Operations

FIWAREFeatureIoTDataEdge-

CepheusCEPNGSIConfiguration

FIWAREEpicIoTIotDataEdgeCo

nsolidationBroker

FIWAREEpicIoTIotDataEdgeCo

nsolidationCommonDataModel

FIWAREEpicIoTIotDataEdgeCo

nsolidationComplexEventProce

ssing

FIWAREEpicIoTIotDataEdgeCo

nsolidationManager

43 Future releases

The following features and epics correspond to features that are in the roadmap of the respective

Generic Enablers but are not going to be implemented as part of FIWARE project activities Some of

them may continue under the FIWARE Community activities some others will not

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 16

You can check out the previous releases of this FIWARE chapter on Roadmap of Internet of Things (IoT)

Services(previous releases)

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 17

5 Backend Device Management GE

51 IDAS Modularity Epic

Name Refactoring

IoT Agents

Chapter IoT

Goal Evolution of the architecture and implementation according to developers

feedback

Description To evolve from a C++ monolithic architecture (extensible via C++ plugins) towards

a modular design where each module (IoT Agent) focusses on a reduce set of IoT

Southbound Protocols and is written in any language This will significantly reduce

the complexity of installation and operation of this component

Rationale Lighter architecture and easier installation operation and extensibility The idea is

to provide modules (IoT Agents) for one or a reduced number of IoT southbound

protocols for easier installation and improved operations and scalability

52 IDAS Protocols Epic

Name New

Protocols

- IoT

Agents

Chapter

IoT

Goal Evolution of the architecture and implementation according to industry trends

Description Besides providing backwards compatibility new southbound technologies and

protocols need to be adopted as long as there are new proposals comming from

Industrial alliances and also open and propietary standards that are relavnt

enough to be adopted

Rationale To make FIWARE IoT competitive regarding the latest emerging trends and

industrial propositions The idea behind the IoT agents is to provide such an easy

extensibility and IoT Agents skeletons are provided to developers (in C++ and

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 18

nodejs) so they can also add new protocols if needed

53 IDAS DevKit Epic

Name FIGWAY

Testing

Tools

Chapter

IoT

Goal Provide a set of testing and training tools regarding FIWARE IoT

Description To provide means for experimenting with different kinds of virtual or pyhical

sensor and actuators Particularly virtual sensors emnable simulations and Apps

developmen t before installing devices in place allowing issues antcipation and

improving time to market of IoT projects

Rationale Easy learning testing and training with FIWARE IoT by providing software tools to

be installed in gateways andor laptops desktop PCs etc to perform simulations

54 IDAS GeoDescription Epic

Name Geographical

Description

Chapter IoT

Goal Identify standard methods to add geolocation data to IoT devices so that graphical

representation can be improved

Description Identify standard methods and protocols to add geolocation data to IoT devices so

that graphical representation can be improved Therea re many available options

but the one that is being worked out in the data chapter for the 2D and 3D

interfaces has been finally selected

Rationale Improve graphical presentation of IoT by providing a standar way to add location

metadata to the devices themselves The specification guarantees the

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 19

compatibility with the FIWARE 2D and 3D user interfaces

55 IDAS EdgeManagement Epic

Name IoT Edge

Management

Chapter IoT

Goal Provide an easy way to configure underlaying southbound infrastructure

(gateways networks connectivity security etc)

Description To make the life of IoT providers easier with platform tools So far IDAS was

mainly focussed on translating southbound IoT protocols intro NGSI but this EPIC

will cover the easy deployment and operations of Edge related elements

(gateways connectivity etc)

Rationale The idea behind this EPIC is to make IoT deployments easier and consider the

feedback provided by developers and integrators on this specific area

56 Modularity ndash Homogeneous Commands Feature

Name BE

DeviceManagement

Homogeneous

Commands

Chapter

IoT

Goal Implement the new specs for commands (real-time andor polling) for all IoT

Agents

Description This feature aligns all IoT Agents regarding commands delivery The idea is to

have a common specification for all the ADMIN API and Commands API of the

different IoT Agents

Rationale Provide a common ADMIN API and Commands API for all IoT Agents The

ADMIN API is a REST HTTP API that is similar to the IoT Manager one and it

enables Admins to provision devices services subservices and other

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 20

configurable elements

57 Modularity ndash Devices Timezone Feature

Name BE

DeviceManagement

Device Timezone

Functions

Chapter

IoT

Goal Implement a Timezone function (devices not in GMT) for all IoT Agents

Description This feature aligns all IoT Agents to be able to configure the timezone of

devices The idea is to have a common specification for all the ADMIN API of

the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST

HTTP API that is similar to the IoT Manager one and it enables Admins to

provision devices services subservices and other configurable elements

58 Modularity ndash Device Life Cicle Feature

Name BE

DeviceManagement

Device Life Cicle

Functions

Chapter

IoT

Goal Implement Device Life Cicle functions (enabledisable in addition to

provisiondelete) for all IoT Agents

Description This feature aligns all IoT Agents to be able to manage devices and other

configurable elements (for instance configure a service to accept only pre-

provisioned devices) The idea is to have a common specification for all the

ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 11: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 11

4 Roadmap of Internet of Things (IoT) Services

41 Introduction

The Internet of Things Service Enablement chapter in FIWARE provides key assets enabling access to IoT

resources

You can learn more about the IoT Chapter by reading the FIWARE Architecture and Open Specifications

Following is a description of the Technical Roadmap planned for the chapter which will be developed

through subsequent Releases of the FIWARE Platform Please also check the Releases and Sprints

numbering with mapping to calendar dates

42 Fifth Major Release

Following is a description of features per Generic Enablers that will be supported in Release 5 of

FIWARE both in the backend and gateway parts

421 Backend

4211 Backend Device Management

o Addition of new IoT protocols by means of new dedicated IoT Agents Examples

OneM2M (inlcuding MCA northbound interface) amp Modbus

o Development of IoT Agents at the Gateway level Mainly to replace the previous

Protocol Adapater GE

o Deliver new SDKs for different hardware platforms Arduino Cludino Intel Edision

ThinkingThings Open RaspberryPI etc

o Enable new features such as Device Management IoT infrastructure management

(using NGSI entities) etc

o Migration of all IoT Agents to nodejs implementations

4212 Backend IoT Broker

o intelligent update request handling

o efficient and energy saving IoT subsystem invocation

o Enhance interface capabilities

o harmonize additional interface features towards NGSI v2 support

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 12

4213 Backend IoT Discovery

o Support geo-location discovery of entities

o evolve (semantic) linked-data platform API to 2nd version

o evolve NGSI API to 2nd version

o provide ontology for IoT entities

o provide a dataset generator for initial testing

o change store from object database to document store

FIWARE

GE Supported Features Epics under analysis

Backend

Device

Manage

ment

Release 51

FIWAREFeatureIoTIDASModularityHomog

eneousCommands

FIWAREFeatureIoTIDASModularityDevices

Timezone

FIWAREFeatureIoTIDASModularityDeviceL

ifeCicle

FIWAREFeatureIoTIDASModularityDeleteF

unctions

Release 52

FIWAREFeatureIoTIDASProtocolsOneM2M

Basic

FIWAREFeatureIoTIDASDevKitSDKIntelEdis

on

FIWAREFeatureIoTIDASDevKitSDKArduino

Release 53

FIWAREFeatureIoTIDASProtocolsnodejsMi

gration

FIWAREFeatureIoTIDASModularityNewGit

hubOrganization

FIWAREFeatureIoTIDASModularityImprov

eOperations

FIWAREEpicIoTIDASModula

rity

FIWAREEpicIoTIDASProtoc

ols

FIWAREEpicIoTIDASDevKit

FIWAREEpicIoTIDASGeoDes

cription

FIWAREEpicIoTIDASEdgeM

anagement

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 13

Release 54

FIWAREFeatureIoTIDASModularityIoTMan

agerAdvanced

FIWAREFeatureIoTIDASEdgeManagementI

oTInfrastructure

FIWAREFeatureIoTIDASGeoDescriptionPOI

s-Integration

Backend

IoT

Broker

Release 51

FIWAREFeatureIoTBackendIoTBrokerSmart

UpdateHandler

Release 52

FIWAREFeatureIoTBackendIoTBrokerHistor

yQueries

FIWAREFeatureIoTBackendIoTBrokerAdva

ncedQueries

Release 53

FIWAREFeatureIoTBackendIoTBrokerInterf

aceNGSIv2

Release 54

IoT

Discover

y

Release 51

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9GeoLocation

FIWAREFeatureIoTIoTDiscoveryInterfaceS

emanticRegApiV2

FIWAREFeatureIoTIoTDiscoveryRepository

DatasetGenerator

Release 52

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

FIWAREFeatureIoTIoTDiscoveryInterfaceN

FIWAREEpicIoTIoTDiscovery

Interface

FIWAREEpicIoTIoTDiscovery

Interoperability

FIWAREEpicIoTIoTDiscovery

Repository

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 14

gsiV2

Release 53

FIWAREFeatureIoTIoTDiscoveryInterfaceN

gsiV2

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

Release 54

FIWAREFeatureIoTIoTDiscoveryInterface

WebUI

422 Gateway

4221 IoT Data Edge Consolidation

The main effort in release 5 is to be compliant NGSI V2 and to improve the robustness of the broker and

the CEP

o the CEP will offer geofencing operations

o the broker will be compliant ngsi9

o the broker and the CEP will interface with other GE with NGSI V2

FIWAR

E GE Supported Features Epics under analysis

IoT

Data

Edge

Consol

idatio

Release 51

FIWAREFeatureIoTIotDataEdgeConsolidati

onLocalStoragepubsub

FIWAREEpicIoTIotDataEdgeCo

nsolidationLocalStorage

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 15

n FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2GeolocTimes

tamp

FIWAREFeatureIoTIotDataEdgeConsolidati

onBrokerFilterUpdateContext

FIWAREFeatureIoTIotDataEdgeConsolidati

onComplexEventProcessingComplexType

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSI9

Release 52

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2

Release 53

FIWAREFeatureIoTIotDataEdgeConsolidati

onManagerNgsiConfiguration

Release 54

FIWAREFeatureIoTDataEdge-

CepheusNGSI9Operations

FIWAREFeatureIoTDataEdge-

CepheusCEPNGSIConfiguration

FIWAREEpicIoTIotDataEdgeCo

nsolidationBroker

FIWAREEpicIoTIotDataEdgeCo

nsolidationCommonDataModel

FIWAREEpicIoTIotDataEdgeCo

nsolidationComplexEventProce

ssing

FIWAREEpicIoTIotDataEdgeCo

nsolidationManager

43 Future releases

The following features and epics correspond to features that are in the roadmap of the respective

Generic Enablers but are not going to be implemented as part of FIWARE project activities Some of

them may continue under the FIWARE Community activities some others will not

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 16

You can check out the previous releases of this FIWARE chapter on Roadmap of Internet of Things (IoT)

Services(previous releases)

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 17

5 Backend Device Management GE

51 IDAS Modularity Epic

Name Refactoring

IoT Agents

Chapter IoT

Goal Evolution of the architecture and implementation according to developers

feedback

Description To evolve from a C++ monolithic architecture (extensible via C++ plugins) towards

a modular design where each module (IoT Agent) focusses on a reduce set of IoT

Southbound Protocols and is written in any language This will significantly reduce

the complexity of installation and operation of this component

Rationale Lighter architecture and easier installation operation and extensibility The idea is

to provide modules (IoT Agents) for one or a reduced number of IoT southbound

protocols for easier installation and improved operations and scalability

52 IDAS Protocols Epic

Name New

Protocols

- IoT

Agents

Chapter

IoT

Goal Evolution of the architecture and implementation according to industry trends

Description Besides providing backwards compatibility new southbound technologies and

protocols need to be adopted as long as there are new proposals comming from

Industrial alliances and also open and propietary standards that are relavnt

enough to be adopted

Rationale To make FIWARE IoT competitive regarding the latest emerging trends and

industrial propositions The idea behind the IoT agents is to provide such an easy

extensibility and IoT Agents skeletons are provided to developers (in C++ and

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 18

nodejs) so they can also add new protocols if needed

53 IDAS DevKit Epic

Name FIGWAY

Testing

Tools

Chapter

IoT

Goal Provide a set of testing and training tools regarding FIWARE IoT

Description To provide means for experimenting with different kinds of virtual or pyhical

sensor and actuators Particularly virtual sensors emnable simulations and Apps

developmen t before installing devices in place allowing issues antcipation and

improving time to market of IoT projects

Rationale Easy learning testing and training with FIWARE IoT by providing software tools to

be installed in gateways andor laptops desktop PCs etc to perform simulations

54 IDAS GeoDescription Epic

Name Geographical

Description

Chapter IoT

Goal Identify standard methods to add geolocation data to IoT devices so that graphical

representation can be improved

Description Identify standard methods and protocols to add geolocation data to IoT devices so

that graphical representation can be improved Therea re many available options

but the one that is being worked out in the data chapter for the 2D and 3D

interfaces has been finally selected

Rationale Improve graphical presentation of IoT by providing a standar way to add location

metadata to the devices themselves The specification guarantees the

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 19

compatibility with the FIWARE 2D and 3D user interfaces

55 IDAS EdgeManagement Epic

Name IoT Edge

Management

Chapter IoT

Goal Provide an easy way to configure underlaying southbound infrastructure

(gateways networks connectivity security etc)

Description To make the life of IoT providers easier with platform tools So far IDAS was

mainly focussed on translating southbound IoT protocols intro NGSI but this EPIC

will cover the easy deployment and operations of Edge related elements

(gateways connectivity etc)

Rationale The idea behind this EPIC is to make IoT deployments easier and consider the

feedback provided by developers and integrators on this specific area

56 Modularity ndash Homogeneous Commands Feature

Name BE

DeviceManagement

Homogeneous

Commands

Chapter

IoT

Goal Implement the new specs for commands (real-time andor polling) for all IoT

Agents

Description This feature aligns all IoT Agents regarding commands delivery The idea is to

have a common specification for all the ADMIN API and Commands API of the

different IoT Agents

Rationale Provide a common ADMIN API and Commands API for all IoT Agents The

ADMIN API is a REST HTTP API that is similar to the IoT Manager one and it

enables Admins to provision devices services subservices and other

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 20

configurable elements

57 Modularity ndash Devices Timezone Feature

Name BE

DeviceManagement

Device Timezone

Functions

Chapter

IoT

Goal Implement a Timezone function (devices not in GMT) for all IoT Agents

Description This feature aligns all IoT Agents to be able to configure the timezone of

devices The idea is to have a common specification for all the ADMIN API of

the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST

HTTP API that is similar to the IoT Manager one and it enables Admins to

provision devices services subservices and other configurable elements

58 Modularity ndash Device Life Cicle Feature

Name BE

DeviceManagement

Device Life Cicle

Functions

Chapter

IoT

Goal Implement Device Life Cicle functions (enabledisable in addition to

provisiondelete) for all IoT Agents

Description This feature aligns all IoT Agents to be able to manage devices and other

configurable elements (for instance configure a service to accept only pre-

provisioned devices) The idea is to have a common specification for all the

ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 12: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 12

4213 Backend IoT Discovery

o Support geo-location discovery of entities

o evolve (semantic) linked-data platform API to 2nd version

o evolve NGSI API to 2nd version

o provide ontology for IoT entities

o provide a dataset generator for initial testing

o change store from object database to document store

FIWARE

GE Supported Features Epics under analysis

Backend

Device

Manage

ment

Release 51

FIWAREFeatureIoTIDASModularityHomog

eneousCommands

FIWAREFeatureIoTIDASModularityDevices

Timezone

FIWAREFeatureIoTIDASModularityDeviceL

ifeCicle

FIWAREFeatureIoTIDASModularityDeleteF

unctions

Release 52

FIWAREFeatureIoTIDASProtocolsOneM2M

Basic

FIWAREFeatureIoTIDASDevKitSDKIntelEdis

on

FIWAREFeatureIoTIDASDevKitSDKArduino

Release 53

FIWAREFeatureIoTIDASProtocolsnodejsMi

gration

FIWAREFeatureIoTIDASModularityNewGit

hubOrganization

FIWAREFeatureIoTIDASModularityImprov

eOperations

FIWAREEpicIoTIDASModula

rity

FIWAREEpicIoTIDASProtoc

ols

FIWAREEpicIoTIDASDevKit

FIWAREEpicIoTIDASGeoDes

cription

FIWAREEpicIoTIDASEdgeM

anagement

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 13

Release 54

FIWAREFeatureIoTIDASModularityIoTMan

agerAdvanced

FIWAREFeatureIoTIDASEdgeManagementI

oTInfrastructure

FIWAREFeatureIoTIDASGeoDescriptionPOI

s-Integration

Backend

IoT

Broker

Release 51

FIWAREFeatureIoTBackendIoTBrokerSmart

UpdateHandler

Release 52

FIWAREFeatureIoTBackendIoTBrokerHistor

yQueries

FIWAREFeatureIoTBackendIoTBrokerAdva

ncedQueries

Release 53

FIWAREFeatureIoTBackendIoTBrokerInterf

aceNGSIv2

Release 54

IoT

Discover

y

Release 51

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9GeoLocation

FIWAREFeatureIoTIoTDiscoveryInterfaceS

emanticRegApiV2

FIWAREFeatureIoTIoTDiscoveryRepository

DatasetGenerator

Release 52

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

FIWAREFeatureIoTIoTDiscoveryInterfaceN

FIWAREEpicIoTIoTDiscovery

Interface

FIWAREEpicIoTIoTDiscovery

Interoperability

FIWAREEpicIoTIoTDiscovery

Repository

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 14

gsiV2

Release 53

FIWAREFeatureIoTIoTDiscoveryInterfaceN

gsiV2

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

Release 54

FIWAREFeatureIoTIoTDiscoveryInterface

WebUI

422 Gateway

4221 IoT Data Edge Consolidation

The main effort in release 5 is to be compliant NGSI V2 and to improve the robustness of the broker and

the CEP

o the CEP will offer geofencing operations

o the broker will be compliant ngsi9

o the broker and the CEP will interface with other GE with NGSI V2

FIWAR

E GE Supported Features Epics under analysis

IoT

Data

Edge

Consol

idatio

Release 51

FIWAREFeatureIoTIotDataEdgeConsolidati

onLocalStoragepubsub

FIWAREEpicIoTIotDataEdgeCo

nsolidationLocalStorage

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 15

n FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2GeolocTimes

tamp

FIWAREFeatureIoTIotDataEdgeConsolidati

onBrokerFilterUpdateContext

FIWAREFeatureIoTIotDataEdgeConsolidati

onComplexEventProcessingComplexType

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSI9

Release 52

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2

Release 53

FIWAREFeatureIoTIotDataEdgeConsolidati

onManagerNgsiConfiguration

Release 54

FIWAREFeatureIoTDataEdge-

CepheusNGSI9Operations

FIWAREFeatureIoTDataEdge-

CepheusCEPNGSIConfiguration

FIWAREEpicIoTIotDataEdgeCo

nsolidationBroker

FIWAREEpicIoTIotDataEdgeCo

nsolidationCommonDataModel

FIWAREEpicIoTIotDataEdgeCo

nsolidationComplexEventProce

ssing

FIWAREEpicIoTIotDataEdgeCo

nsolidationManager

43 Future releases

The following features and epics correspond to features that are in the roadmap of the respective

Generic Enablers but are not going to be implemented as part of FIWARE project activities Some of

them may continue under the FIWARE Community activities some others will not

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 16

You can check out the previous releases of this FIWARE chapter on Roadmap of Internet of Things (IoT)

Services(previous releases)

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 17

5 Backend Device Management GE

51 IDAS Modularity Epic

Name Refactoring

IoT Agents

Chapter IoT

Goal Evolution of the architecture and implementation according to developers

feedback

Description To evolve from a C++ monolithic architecture (extensible via C++ plugins) towards

a modular design where each module (IoT Agent) focusses on a reduce set of IoT

Southbound Protocols and is written in any language This will significantly reduce

the complexity of installation and operation of this component

Rationale Lighter architecture and easier installation operation and extensibility The idea is

to provide modules (IoT Agents) for one or a reduced number of IoT southbound

protocols for easier installation and improved operations and scalability

52 IDAS Protocols Epic

Name New

Protocols

- IoT

Agents

Chapter

IoT

Goal Evolution of the architecture and implementation according to industry trends

Description Besides providing backwards compatibility new southbound technologies and

protocols need to be adopted as long as there are new proposals comming from

Industrial alliances and also open and propietary standards that are relavnt

enough to be adopted

Rationale To make FIWARE IoT competitive regarding the latest emerging trends and

industrial propositions The idea behind the IoT agents is to provide such an easy

extensibility and IoT Agents skeletons are provided to developers (in C++ and

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 18

nodejs) so they can also add new protocols if needed

53 IDAS DevKit Epic

Name FIGWAY

Testing

Tools

Chapter

IoT

Goal Provide a set of testing and training tools regarding FIWARE IoT

Description To provide means for experimenting with different kinds of virtual or pyhical

sensor and actuators Particularly virtual sensors emnable simulations and Apps

developmen t before installing devices in place allowing issues antcipation and

improving time to market of IoT projects

Rationale Easy learning testing and training with FIWARE IoT by providing software tools to

be installed in gateways andor laptops desktop PCs etc to perform simulations

54 IDAS GeoDescription Epic

Name Geographical

Description

Chapter IoT

Goal Identify standard methods to add geolocation data to IoT devices so that graphical

representation can be improved

Description Identify standard methods and protocols to add geolocation data to IoT devices so

that graphical representation can be improved Therea re many available options

but the one that is being worked out in the data chapter for the 2D and 3D

interfaces has been finally selected

Rationale Improve graphical presentation of IoT by providing a standar way to add location

metadata to the devices themselves The specification guarantees the

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 19

compatibility with the FIWARE 2D and 3D user interfaces

55 IDAS EdgeManagement Epic

Name IoT Edge

Management

Chapter IoT

Goal Provide an easy way to configure underlaying southbound infrastructure

(gateways networks connectivity security etc)

Description To make the life of IoT providers easier with platform tools So far IDAS was

mainly focussed on translating southbound IoT protocols intro NGSI but this EPIC

will cover the easy deployment and operations of Edge related elements

(gateways connectivity etc)

Rationale The idea behind this EPIC is to make IoT deployments easier and consider the

feedback provided by developers and integrators on this specific area

56 Modularity ndash Homogeneous Commands Feature

Name BE

DeviceManagement

Homogeneous

Commands

Chapter

IoT

Goal Implement the new specs for commands (real-time andor polling) for all IoT

Agents

Description This feature aligns all IoT Agents regarding commands delivery The idea is to

have a common specification for all the ADMIN API and Commands API of the

different IoT Agents

Rationale Provide a common ADMIN API and Commands API for all IoT Agents The

ADMIN API is a REST HTTP API that is similar to the IoT Manager one and it

enables Admins to provision devices services subservices and other

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 20

configurable elements

57 Modularity ndash Devices Timezone Feature

Name BE

DeviceManagement

Device Timezone

Functions

Chapter

IoT

Goal Implement a Timezone function (devices not in GMT) for all IoT Agents

Description This feature aligns all IoT Agents to be able to configure the timezone of

devices The idea is to have a common specification for all the ADMIN API of

the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST

HTTP API that is similar to the IoT Manager one and it enables Admins to

provision devices services subservices and other configurable elements

58 Modularity ndash Device Life Cicle Feature

Name BE

DeviceManagement

Device Life Cicle

Functions

Chapter

IoT

Goal Implement Device Life Cicle functions (enabledisable in addition to

provisiondelete) for all IoT Agents

Description This feature aligns all IoT Agents to be able to manage devices and other

configurable elements (for instance configure a service to accept only pre-

provisioned devices) The idea is to have a common specification for all the

ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 13: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 13

Release 54

FIWAREFeatureIoTIDASModularityIoTMan

agerAdvanced

FIWAREFeatureIoTIDASEdgeManagementI

oTInfrastructure

FIWAREFeatureIoTIDASGeoDescriptionPOI

s-Integration

Backend

IoT

Broker

Release 51

FIWAREFeatureIoTBackendIoTBrokerSmart

UpdateHandler

Release 52

FIWAREFeatureIoTBackendIoTBrokerHistor

yQueries

FIWAREFeatureIoTBackendIoTBrokerAdva

ncedQueries

Release 53

FIWAREFeatureIoTBackendIoTBrokerInterf

aceNGSIv2

Release 54

IoT

Discover

y

Release 51

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9GeoLocation

FIWAREFeatureIoTIoTDiscoveryInterfaceS

emanticRegApiV2

FIWAREFeatureIoTIoTDiscoveryRepository

DatasetGenerator

Release 52

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

FIWAREFeatureIoTIoTDiscoveryInterfaceN

FIWAREEpicIoTIoTDiscovery

Interface

FIWAREEpicIoTIoTDiscovery

Interoperability

FIWAREEpicIoTIoTDiscovery

Repository

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 14

gsiV2

Release 53

FIWAREFeatureIoTIoTDiscoveryInterfaceN

gsiV2

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

Release 54

FIWAREFeatureIoTIoTDiscoveryInterface

WebUI

422 Gateway

4221 IoT Data Edge Consolidation

The main effort in release 5 is to be compliant NGSI V2 and to improve the robustness of the broker and

the CEP

o the CEP will offer geofencing operations

o the broker will be compliant ngsi9

o the broker and the CEP will interface with other GE with NGSI V2

FIWAR

E GE Supported Features Epics under analysis

IoT

Data

Edge

Consol

idatio

Release 51

FIWAREFeatureIoTIotDataEdgeConsolidati

onLocalStoragepubsub

FIWAREEpicIoTIotDataEdgeCo

nsolidationLocalStorage

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 15

n FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2GeolocTimes

tamp

FIWAREFeatureIoTIotDataEdgeConsolidati

onBrokerFilterUpdateContext

FIWAREFeatureIoTIotDataEdgeConsolidati

onComplexEventProcessingComplexType

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSI9

Release 52

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2

Release 53

FIWAREFeatureIoTIotDataEdgeConsolidati

onManagerNgsiConfiguration

Release 54

FIWAREFeatureIoTDataEdge-

CepheusNGSI9Operations

FIWAREFeatureIoTDataEdge-

CepheusCEPNGSIConfiguration

FIWAREEpicIoTIotDataEdgeCo

nsolidationBroker

FIWAREEpicIoTIotDataEdgeCo

nsolidationCommonDataModel

FIWAREEpicIoTIotDataEdgeCo

nsolidationComplexEventProce

ssing

FIWAREEpicIoTIotDataEdgeCo

nsolidationManager

43 Future releases

The following features and epics correspond to features that are in the roadmap of the respective

Generic Enablers but are not going to be implemented as part of FIWARE project activities Some of

them may continue under the FIWARE Community activities some others will not

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 16

You can check out the previous releases of this FIWARE chapter on Roadmap of Internet of Things (IoT)

Services(previous releases)

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 17

5 Backend Device Management GE

51 IDAS Modularity Epic

Name Refactoring

IoT Agents

Chapter IoT

Goal Evolution of the architecture and implementation according to developers

feedback

Description To evolve from a C++ monolithic architecture (extensible via C++ plugins) towards

a modular design where each module (IoT Agent) focusses on a reduce set of IoT

Southbound Protocols and is written in any language This will significantly reduce

the complexity of installation and operation of this component

Rationale Lighter architecture and easier installation operation and extensibility The idea is

to provide modules (IoT Agents) for one or a reduced number of IoT southbound

protocols for easier installation and improved operations and scalability

52 IDAS Protocols Epic

Name New

Protocols

- IoT

Agents

Chapter

IoT

Goal Evolution of the architecture and implementation according to industry trends

Description Besides providing backwards compatibility new southbound technologies and

protocols need to be adopted as long as there are new proposals comming from

Industrial alliances and also open and propietary standards that are relavnt

enough to be adopted

Rationale To make FIWARE IoT competitive regarding the latest emerging trends and

industrial propositions The idea behind the IoT agents is to provide such an easy

extensibility and IoT Agents skeletons are provided to developers (in C++ and

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 18

nodejs) so they can also add new protocols if needed

53 IDAS DevKit Epic

Name FIGWAY

Testing

Tools

Chapter

IoT

Goal Provide a set of testing and training tools regarding FIWARE IoT

Description To provide means for experimenting with different kinds of virtual or pyhical

sensor and actuators Particularly virtual sensors emnable simulations and Apps

developmen t before installing devices in place allowing issues antcipation and

improving time to market of IoT projects

Rationale Easy learning testing and training with FIWARE IoT by providing software tools to

be installed in gateways andor laptops desktop PCs etc to perform simulations

54 IDAS GeoDescription Epic

Name Geographical

Description

Chapter IoT

Goal Identify standard methods to add geolocation data to IoT devices so that graphical

representation can be improved

Description Identify standard methods and protocols to add geolocation data to IoT devices so

that graphical representation can be improved Therea re many available options

but the one that is being worked out in the data chapter for the 2D and 3D

interfaces has been finally selected

Rationale Improve graphical presentation of IoT by providing a standar way to add location

metadata to the devices themselves The specification guarantees the

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 19

compatibility with the FIWARE 2D and 3D user interfaces

55 IDAS EdgeManagement Epic

Name IoT Edge

Management

Chapter IoT

Goal Provide an easy way to configure underlaying southbound infrastructure

(gateways networks connectivity security etc)

Description To make the life of IoT providers easier with platform tools So far IDAS was

mainly focussed on translating southbound IoT protocols intro NGSI but this EPIC

will cover the easy deployment and operations of Edge related elements

(gateways connectivity etc)

Rationale The idea behind this EPIC is to make IoT deployments easier and consider the

feedback provided by developers and integrators on this specific area

56 Modularity ndash Homogeneous Commands Feature

Name BE

DeviceManagement

Homogeneous

Commands

Chapter

IoT

Goal Implement the new specs for commands (real-time andor polling) for all IoT

Agents

Description This feature aligns all IoT Agents regarding commands delivery The idea is to

have a common specification for all the ADMIN API and Commands API of the

different IoT Agents

Rationale Provide a common ADMIN API and Commands API for all IoT Agents The

ADMIN API is a REST HTTP API that is similar to the IoT Manager one and it

enables Admins to provision devices services subservices and other

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 20

configurable elements

57 Modularity ndash Devices Timezone Feature

Name BE

DeviceManagement

Device Timezone

Functions

Chapter

IoT

Goal Implement a Timezone function (devices not in GMT) for all IoT Agents

Description This feature aligns all IoT Agents to be able to configure the timezone of

devices The idea is to have a common specification for all the ADMIN API of

the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST

HTTP API that is similar to the IoT Manager one and it enables Admins to

provision devices services subservices and other configurable elements

58 Modularity ndash Device Life Cicle Feature

Name BE

DeviceManagement

Device Life Cicle

Functions

Chapter

IoT

Goal Implement Device Life Cicle functions (enabledisable in addition to

provisiondelete) for all IoT Agents

Description This feature aligns all IoT Agents to be able to manage devices and other

configurable elements (for instance configure a service to accept only pre-

provisioned devices) The idea is to have a common specification for all the

ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 14: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 14

gsiV2

Release 53

FIWAREFeatureIoTIoTDiscoveryInterfaceN

gsiV2

FIWAREFeatureIoTIoTDiscoveryRepository

Ngsi9OnDocumentStore

Release 54

FIWAREFeatureIoTIoTDiscoveryInterface

WebUI

422 Gateway

4221 IoT Data Edge Consolidation

The main effort in release 5 is to be compliant NGSI V2 and to improve the robustness of the broker and

the CEP

o the CEP will offer geofencing operations

o the broker will be compliant ngsi9

o the broker and the CEP will interface with other GE with NGSI V2

FIWAR

E GE Supported Features Epics under analysis

IoT

Data

Edge

Consol

idatio

Release 51

FIWAREFeatureIoTIotDataEdgeConsolidati

onLocalStoragepubsub

FIWAREEpicIoTIotDataEdgeCo

nsolidationLocalStorage

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 15

n FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2GeolocTimes

tamp

FIWAREFeatureIoTIotDataEdgeConsolidati

onBrokerFilterUpdateContext

FIWAREFeatureIoTIotDataEdgeConsolidati

onComplexEventProcessingComplexType

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSI9

Release 52

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2

Release 53

FIWAREFeatureIoTIotDataEdgeConsolidati

onManagerNgsiConfiguration

Release 54

FIWAREFeatureIoTDataEdge-

CepheusNGSI9Operations

FIWAREFeatureIoTDataEdge-

CepheusCEPNGSIConfiguration

FIWAREEpicIoTIotDataEdgeCo

nsolidationBroker

FIWAREEpicIoTIotDataEdgeCo

nsolidationCommonDataModel

FIWAREEpicIoTIotDataEdgeCo

nsolidationComplexEventProce

ssing

FIWAREEpicIoTIotDataEdgeCo

nsolidationManager

43 Future releases

The following features and epics correspond to features that are in the roadmap of the respective

Generic Enablers but are not going to be implemented as part of FIWARE project activities Some of

them may continue under the FIWARE Community activities some others will not

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 16

You can check out the previous releases of this FIWARE chapter on Roadmap of Internet of Things (IoT)

Services(previous releases)

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 17

5 Backend Device Management GE

51 IDAS Modularity Epic

Name Refactoring

IoT Agents

Chapter IoT

Goal Evolution of the architecture and implementation according to developers

feedback

Description To evolve from a C++ monolithic architecture (extensible via C++ plugins) towards

a modular design where each module (IoT Agent) focusses on a reduce set of IoT

Southbound Protocols and is written in any language This will significantly reduce

the complexity of installation and operation of this component

Rationale Lighter architecture and easier installation operation and extensibility The idea is

to provide modules (IoT Agents) for one or a reduced number of IoT southbound

protocols for easier installation and improved operations and scalability

52 IDAS Protocols Epic

Name New

Protocols

- IoT

Agents

Chapter

IoT

Goal Evolution of the architecture and implementation according to industry trends

Description Besides providing backwards compatibility new southbound technologies and

protocols need to be adopted as long as there are new proposals comming from

Industrial alliances and also open and propietary standards that are relavnt

enough to be adopted

Rationale To make FIWARE IoT competitive regarding the latest emerging trends and

industrial propositions The idea behind the IoT agents is to provide such an easy

extensibility and IoT Agents skeletons are provided to developers (in C++ and

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 18

nodejs) so they can also add new protocols if needed

53 IDAS DevKit Epic

Name FIGWAY

Testing

Tools

Chapter

IoT

Goal Provide a set of testing and training tools regarding FIWARE IoT

Description To provide means for experimenting with different kinds of virtual or pyhical

sensor and actuators Particularly virtual sensors emnable simulations and Apps

developmen t before installing devices in place allowing issues antcipation and

improving time to market of IoT projects

Rationale Easy learning testing and training with FIWARE IoT by providing software tools to

be installed in gateways andor laptops desktop PCs etc to perform simulations

54 IDAS GeoDescription Epic

Name Geographical

Description

Chapter IoT

Goal Identify standard methods to add geolocation data to IoT devices so that graphical

representation can be improved

Description Identify standard methods and protocols to add geolocation data to IoT devices so

that graphical representation can be improved Therea re many available options

but the one that is being worked out in the data chapter for the 2D and 3D

interfaces has been finally selected

Rationale Improve graphical presentation of IoT by providing a standar way to add location

metadata to the devices themselves The specification guarantees the

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 19

compatibility with the FIWARE 2D and 3D user interfaces

55 IDAS EdgeManagement Epic

Name IoT Edge

Management

Chapter IoT

Goal Provide an easy way to configure underlaying southbound infrastructure

(gateways networks connectivity security etc)

Description To make the life of IoT providers easier with platform tools So far IDAS was

mainly focussed on translating southbound IoT protocols intro NGSI but this EPIC

will cover the easy deployment and operations of Edge related elements

(gateways connectivity etc)

Rationale The idea behind this EPIC is to make IoT deployments easier and consider the

feedback provided by developers and integrators on this specific area

56 Modularity ndash Homogeneous Commands Feature

Name BE

DeviceManagement

Homogeneous

Commands

Chapter

IoT

Goal Implement the new specs for commands (real-time andor polling) for all IoT

Agents

Description This feature aligns all IoT Agents regarding commands delivery The idea is to

have a common specification for all the ADMIN API and Commands API of the

different IoT Agents

Rationale Provide a common ADMIN API and Commands API for all IoT Agents The

ADMIN API is a REST HTTP API that is similar to the IoT Manager one and it

enables Admins to provision devices services subservices and other

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 20

configurable elements

57 Modularity ndash Devices Timezone Feature

Name BE

DeviceManagement

Device Timezone

Functions

Chapter

IoT

Goal Implement a Timezone function (devices not in GMT) for all IoT Agents

Description This feature aligns all IoT Agents to be able to configure the timezone of

devices The idea is to have a common specification for all the ADMIN API of

the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST

HTTP API that is similar to the IoT Manager one and it enables Admins to

provision devices services subservices and other configurable elements

58 Modularity ndash Device Life Cicle Feature

Name BE

DeviceManagement

Device Life Cicle

Functions

Chapter

IoT

Goal Implement Device Life Cicle functions (enabledisable in addition to

provisiondelete) for all IoT Agents

Description This feature aligns all IoT Agents to be able to manage devices and other

configurable elements (for instance configure a service to accept only pre-

provisioned devices) The idea is to have a common specification for all the

ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 15: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 15

n FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2GeolocTimes

tamp

FIWAREFeatureIoTIotDataEdgeConsolidati

onBrokerFilterUpdateContext

FIWAREFeatureIoTIotDataEdgeConsolidati

onComplexEventProcessingComplexType

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSI9

Release 52

FIWAREFeatureIoTIotDataEdgeConsolidati

onCommonDataModelNGSIV2

Release 53

FIWAREFeatureIoTIotDataEdgeConsolidati

onManagerNgsiConfiguration

Release 54

FIWAREFeatureIoTDataEdge-

CepheusNGSI9Operations

FIWAREFeatureIoTDataEdge-

CepheusCEPNGSIConfiguration

FIWAREEpicIoTIotDataEdgeCo

nsolidationBroker

FIWAREEpicIoTIotDataEdgeCo

nsolidationCommonDataModel

FIWAREEpicIoTIotDataEdgeCo

nsolidationComplexEventProce

ssing

FIWAREEpicIoTIotDataEdgeCo

nsolidationManager

43 Future releases

The following features and epics correspond to features that are in the roadmap of the respective

Generic Enablers but are not going to be implemented as part of FIWARE project activities Some of

them may continue under the FIWARE Community activities some others will not

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 16

You can check out the previous releases of this FIWARE chapter on Roadmap of Internet of Things (IoT)

Services(previous releases)

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 17

5 Backend Device Management GE

51 IDAS Modularity Epic

Name Refactoring

IoT Agents

Chapter IoT

Goal Evolution of the architecture and implementation according to developers

feedback

Description To evolve from a C++ monolithic architecture (extensible via C++ plugins) towards

a modular design where each module (IoT Agent) focusses on a reduce set of IoT

Southbound Protocols and is written in any language This will significantly reduce

the complexity of installation and operation of this component

Rationale Lighter architecture and easier installation operation and extensibility The idea is

to provide modules (IoT Agents) for one or a reduced number of IoT southbound

protocols for easier installation and improved operations and scalability

52 IDAS Protocols Epic

Name New

Protocols

- IoT

Agents

Chapter

IoT

Goal Evolution of the architecture and implementation according to industry trends

Description Besides providing backwards compatibility new southbound technologies and

protocols need to be adopted as long as there are new proposals comming from

Industrial alliances and also open and propietary standards that are relavnt

enough to be adopted

Rationale To make FIWARE IoT competitive regarding the latest emerging trends and

industrial propositions The idea behind the IoT agents is to provide such an easy

extensibility and IoT Agents skeletons are provided to developers (in C++ and

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 18

nodejs) so they can also add new protocols if needed

53 IDAS DevKit Epic

Name FIGWAY

Testing

Tools

Chapter

IoT

Goal Provide a set of testing and training tools regarding FIWARE IoT

Description To provide means for experimenting with different kinds of virtual or pyhical

sensor and actuators Particularly virtual sensors emnable simulations and Apps

developmen t before installing devices in place allowing issues antcipation and

improving time to market of IoT projects

Rationale Easy learning testing and training with FIWARE IoT by providing software tools to

be installed in gateways andor laptops desktop PCs etc to perform simulations

54 IDAS GeoDescription Epic

Name Geographical

Description

Chapter IoT

Goal Identify standard methods to add geolocation data to IoT devices so that graphical

representation can be improved

Description Identify standard methods and protocols to add geolocation data to IoT devices so

that graphical representation can be improved Therea re many available options

but the one that is being worked out in the data chapter for the 2D and 3D

interfaces has been finally selected

Rationale Improve graphical presentation of IoT by providing a standar way to add location

metadata to the devices themselves The specification guarantees the

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 19

compatibility with the FIWARE 2D and 3D user interfaces

55 IDAS EdgeManagement Epic

Name IoT Edge

Management

Chapter IoT

Goal Provide an easy way to configure underlaying southbound infrastructure

(gateways networks connectivity security etc)

Description To make the life of IoT providers easier with platform tools So far IDAS was

mainly focussed on translating southbound IoT protocols intro NGSI but this EPIC

will cover the easy deployment and operations of Edge related elements

(gateways connectivity etc)

Rationale The idea behind this EPIC is to make IoT deployments easier and consider the

feedback provided by developers and integrators on this specific area

56 Modularity ndash Homogeneous Commands Feature

Name BE

DeviceManagement

Homogeneous

Commands

Chapter

IoT

Goal Implement the new specs for commands (real-time andor polling) for all IoT

Agents

Description This feature aligns all IoT Agents regarding commands delivery The idea is to

have a common specification for all the ADMIN API and Commands API of the

different IoT Agents

Rationale Provide a common ADMIN API and Commands API for all IoT Agents The

ADMIN API is a REST HTTP API that is similar to the IoT Manager one and it

enables Admins to provision devices services subservices and other

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 20

configurable elements

57 Modularity ndash Devices Timezone Feature

Name BE

DeviceManagement

Device Timezone

Functions

Chapter

IoT

Goal Implement a Timezone function (devices not in GMT) for all IoT Agents

Description This feature aligns all IoT Agents to be able to configure the timezone of

devices The idea is to have a common specification for all the ADMIN API of

the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST

HTTP API that is similar to the IoT Manager one and it enables Admins to

provision devices services subservices and other configurable elements

58 Modularity ndash Device Life Cicle Feature

Name BE

DeviceManagement

Device Life Cicle

Functions

Chapter

IoT

Goal Implement Device Life Cicle functions (enabledisable in addition to

provisiondelete) for all IoT Agents

Description This feature aligns all IoT Agents to be able to manage devices and other

configurable elements (for instance configure a service to accept only pre-

provisioned devices) The idea is to have a common specification for all the

ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 16: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 16

You can check out the previous releases of this FIWARE chapter on Roadmap of Internet of Things (IoT)

Services(previous releases)

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 17

5 Backend Device Management GE

51 IDAS Modularity Epic

Name Refactoring

IoT Agents

Chapter IoT

Goal Evolution of the architecture and implementation according to developers

feedback

Description To evolve from a C++ monolithic architecture (extensible via C++ plugins) towards

a modular design where each module (IoT Agent) focusses on a reduce set of IoT

Southbound Protocols and is written in any language This will significantly reduce

the complexity of installation and operation of this component

Rationale Lighter architecture and easier installation operation and extensibility The idea is

to provide modules (IoT Agents) for one or a reduced number of IoT southbound

protocols for easier installation and improved operations and scalability

52 IDAS Protocols Epic

Name New

Protocols

- IoT

Agents

Chapter

IoT

Goal Evolution of the architecture and implementation according to industry trends

Description Besides providing backwards compatibility new southbound technologies and

protocols need to be adopted as long as there are new proposals comming from

Industrial alliances and also open and propietary standards that are relavnt

enough to be adopted

Rationale To make FIWARE IoT competitive regarding the latest emerging trends and

industrial propositions The idea behind the IoT agents is to provide such an easy

extensibility and IoT Agents skeletons are provided to developers (in C++ and

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 18

nodejs) so they can also add new protocols if needed

53 IDAS DevKit Epic

Name FIGWAY

Testing

Tools

Chapter

IoT

Goal Provide a set of testing and training tools regarding FIWARE IoT

Description To provide means for experimenting with different kinds of virtual or pyhical

sensor and actuators Particularly virtual sensors emnable simulations and Apps

developmen t before installing devices in place allowing issues antcipation and

improving time to market of IoT projects

Rationale Easy learning testing and training with FIWARE IoT by providing software tools to

be installed in gateways andor laptops desktop PCs etc to perform simulations

54 IDAS GeoDescription Epic

Name Geographical

Description

Chapter IoT

Goal Identify standard methods to add geolocation data to IoT devices so that graphical

representation can be improved

Description Identify standard methods and protocols to add geolocation data to IoT devices so

that graphical representation can be improved Therea re many available options

but the one that is being worked out in the data chapter for the 2D and 3D

interfaces has been finally selected

Rationale Improve graphical presentation of IoT by providing a standar way to add location

metadata to the devices themselves The specification guarantees the

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 19

compatibility with the FIWARE 2D and 3D user interfaces

55 IDAS EdgeManagement Epic

Name IoT Edge

Management

Chapter IoT

Goal Provide an easy way to configure underlaying southbound infrastructure

(gateways networks connectivity security etc)

Description To make the life of IoT providers easier with platform tools So far IDAS was

mainly focussed on translating southbound IoT protocols intro NGSI but this EPIC

will cover the easy deployment and operations of Edge related elements

(gateways connectivity etc)

Rationale The idea behind this EPIC is to make IoT deployments easier and consider the

feedback provided by developers and integrators on this specific area

56 Modularity ndash Homogeneous Commands Feature

Name BE

DeviceManagement

Homogeneous

Commands

Chapter

IoT

Goal Implement the new specs for commands (real-time andor polling) for all IoT

Agents

Description This feature aligns all IoT Agents regarding commands delivery The idea is to

have a common specification for all the ADMIN API and Commands API of the

different IoT Agents

Rationale Provide a common ADMIN API and Commands API for all IoT Agents The

ADMIN API is a REST HTTP API that is similar to the IoT Manager one and it

enables Admins to provision devices services subservices and other

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 20

configurable elements

57 Modularity ndash Devices Timezone Feature

Name BE

DeviceManagement

Device Timezone

Functions

Chapter

IoT

Goal Implement a Timezone function (devices not in GMT) for all IoT Agents

Description This feature aligns all IoT Agents to be able to configure the timezone of

devices The idea is to have a common specification for all the ADMIN API of

the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST

HTTP API that is similar to the IoT Manager one and it enables Admins to

provision devices services subservices and other configurable elements

58 Modularity ndash Device Life Cicle Feature

Name BE

DeviceManagement

Device Life Cicle

Functions

Chapter

IoT

Goal Implement Device Life Cicle functions (enabledisable in addition to

provisiondelete) for all IoT Agents

Description This feature aligns all IoT Agents to be able to manage devices and other

configurable elements (for instance configure a service to accept only pre-

provisioned devices) The idea is to have a common specification for all the

ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 17: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 17

5 Backend Device Management GE

51 IDAS Modularity Epic

Name Refactoring

IoT Agents

Chapter IoT

Goal Evolution of the architecture and implementation according to developers

feedback

Description To evolve from a C++ monolithic architecture (extensible via C++ plugins) towards

a modular design where each module (IoT Agent) focusses on a reduce set of IoT

Southbound Protocols and is written in any language This will significantly reduce

the complexity of installation and operation of this component

Rationale Lighter architecture and easier installation operation and extensibility The idea is

to provide modules (IoT Agents) for one or a reduced number of IoT southbound

protocols for easier installation and improved operations and scalability

52 IDAS Protocols Epic

Name New

Protocols

- IoT

Agents

Chapter

IoT

Goal Evolution of the architecture and implementation according to industry trends

Description Besides providing backwards compatibility new southbound technologies and

protocols need to be adopted as long as there are new proposals comming from

Industrial alliances and also open and propietary standards that are relavnt

enough to be adopted

Rationale To make FIWARE IoT competitive regarding the latest emerging trends and

industrial propositions The idea behind the IoT agents is to provide such an easy

extensibility and IoT Agents skeletons are provided to developers (in C++ and

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 18

nodejs) so they can also add new protocols if needed

53 IDAS DevKit Epic

Name FIGWAY

Testing

Tools

Chapter

IoT

Goal Provide a set of testing and training tools regarding FIWARE IoT

Description To provide means for experimenting with different kinds of virtual or pyhical

sensor and actuators Particularly virtual sensors emnable simulations and Apps

developmen t before installing devices in place allowing issues antcipation and

improving time to market of IoT projects

Rationale Easy learning testing and training with FIWARE IoT by providing software tools to

be installed in gateways andor laptops desktop PCs etc to perform simulations

54 IDAS GeoDescription Epic

Name Geographical

Description

Chapter IoT

Goal Identify standard methods to add geolocation data to IoT devices so that graphical

representation can be improved

Description Identify standard methods and protocols to add geolocation data to IoT devices so

that graphical representation can be improved Therea re many available options

but the one that is being worked out in the data chapter for the 2D and 3D

interfaces has been finally selected

Rationale Improve graphical presentation of IoT by providing a standar way to add location

metadata to the devices themselves The specification guarantees the

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 19

compatibility with the FIWARE 2D and 3D user interfaces

55 IDAS EdgeManagement Epic

Name IoT Edge

Management

Chapter IoT

Goal Provide an easy way to configure underlaying southbound infrastructure

(gateways networks connectivity security etc)

Description To make the life of IoT providers easier with platform tools So far IDAS was

mainly focussed on translating southbound IoT protocols intro NGSI but this EPIC

will cover the easy deployment and operations of Edge related elements

(gateways connectivity etc)

Rationale The idea behind this EPIC is to make IoT deployments easier and consider the

feedback provided by developers and integrators on this specific area

56 Modularity ndash Homogeneous Commands Feature

Name BE

DeviceManagement

Homogeneous

Commands

Chapter

IoT

Goal Implement the new specs for commands (real-time andor polling) for all IoT

Agents

Description This feature aligns all IoT Agents regarding commands delivery The idea is to

have a common specification for all the ADMIN API and Commands API of the

different IoT Agents

Rationale Provide a common ADMIN API and Commands API for all IoT Agents The

ADMIN API is a REST HTTP API that is similar to the IoT Manager one and it

enables Admins to provision devices services subservices and other

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 20

configurable elements

57 Modularity ndash Devices Timezone Feature

Name BE

DeviceManagement

Device Timezone

Functions

Chapter

IoT

Goal Implement a Timezone function (devices not in GMT) for all IoT Agents

Description This feature aligns all IoT Agents to be able to configure the timezone of

devices The idea is to have a common specification for all the ADMIN API of

the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST

HTTP API that is similar to the IoT Manager one and it enables Admins to

provision devices services subservices and other configurable elements

58 Modularity ndash Device Life Cicle Feature

Name BE

DeviceManagement

Device Life Cicle

Functions

Chapter

IoT

Goal Implement Device Life Cicle functions (enabledisable in addition to

provisiondelete) for all IoT Agents

Description This feature aligns all IoT Agents to be able to manage devices and other

configurable elements (for instance configure a service to accept only pre-

provisioned devices) The idea is to have a common specification for all the

ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 18: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 18

nodejs) so they can also add new protocols if needed

53 IDAS DevKit Epic

Name FIGWAY

Testing

Tools

Chapter

IoT

Goal Provide a set of testing and training tools regarding FIWARE IoT

Description To provide means for experimenting with different kinds of virtual or pyhical

sensor and actuators Particularly virtual sensors emnable simulations and Apps

developmen t before installing devices in place allowing issues antcipation and

improving time to market of IoT projects

Rationale Easy learning testing and training with FIWARE IoT by providing software tools to

be installed in gateways andor laptops desktop PCs etc to perform simulations

54 IDAS GeoDescription Epic

Name Geographical

Description

Chapter IoT

Goal Identify standard methods to add geolocation data to IoT devices so that graphical

representation can be improved

Description Identify standard methods and protocols to add geolocation data to IoT devices so

that graphical representation can be improved Therea re many available options

but the one that is being worked out in the data chapter for the 2D and 3D

interfaces has been finally selected

Rationale Improve graphical presentation of IoT by providing a standar way to add location

metadata to the devices themselves The specification guarantees the

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 19

compatibility with the FIWARE 2D and 3D user interfaces

55 IDAS EdgeManagement Epic

Name IoT Edge

Management

Chapter IoT

Goal Provide an easy way to configure underlaying southbound infrastructure

(gateways networks connectivity security etc)

Description To make the life of IoT providers easier with platform tools So far IDAS was

mainly focussed on translating southbound IoT protocols intro NGSI but this EPIC

will cover the easy deployment and operations of Edge related elements

(gateways connectivity etc)

Rationale The idea behind this EPIC is to make IoT deployments easier and consider the

feedback provided by developers and integrators on this specific area

56 Modularity ndash Homogeneous Commands Feature

Name BE

DeviceManagement

Homogeneous

Commands

Chapter

IoT

Goal Implement the new specs for commands (real-time andor polling) for all IoT

Agents

Description This feature aligns all IoT Agents regarding commands delivery The idea is to

have a common specification for all the ADMIN API and Commands API of the

different IoT Agents

Rationale Provide a common ADMIN API and Commands API for all IoT Agents The

ADMIN API is a REST HTTP API that is similar to the IoT Manager one and it

enables Admins to provision devices services subservices and other

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 20

configurable elements

57 Modularity ndash Devices Timezone Feature

Name BE

DeviceManagement

Device Timezone

Functions

Chapter

IoT

Goal Implement a Timezone function (devices not in GMT) for all IoT Agents

Description This feature aligns all IoT Agents to be able to configure the timezone of

devices The idea is to have a common specification for all the ADMIN API of

the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST

HTTP API that is similar to the IoT Manager one and it enables Admins to

provision devices services subservices and other configurable elements

58 Modularity ndash Device Life Cicle Feature

Name BE

DeviceManagement

Device Life Cicle

Functions

Chapter

IoT

Goal Implement Device Life Cicle functions (enabledisable in addition to

provisiondelete) for all IoT Agents

Description This feature aligns all IoT Agents to be able to manage devices and other

configurable elements (for instance configure a service to accept only pre-

provisioned devices) The idea is to have a common specification for all the

ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 19: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 19

compatibility with the FIWARE 2D and 3D user interfaces

55 IDAS EdgeManagement Epic

Name IoT Edge

Management

Chapter IoT

Goal Provide an easy way to configure underlaying southbound infrastructure

(gateways networks connectivity security etc)

Description To make the life of IoT providers easier with platform tools So far IDAS was

mainly focussed on translating southbound IoT protocols intro NGSI but this EPIC

will cover the easy deployment and operations of Edge related elements

(gateways connectivity etc)

Rationale The idea behind this EPIC is to make IoT deployments easier and consider the

feedback provided by developers and integrators on this specific area

56 Modularity ndash Homogeneous Commands Feature

Name BE

DeviceManagement

Homogeneous

Commands

Chapter

IoT

Goal Implement the new specs for commands (real-time andor polling) for all IoT

Agents

Description This feature aligns all IoT Agents regarding commands delivery The idea is to

have a common specification for all the ADMIN API and Commands API of the

different IoT Agents

Rationale Provide a common ADMIN API and Commands API for all IoT Agents The

ADMIN API is a REST HTTP API that is similar to the IoT Manager one and it

enables Admins to provision devices services subservices and other

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 20

configurable elements

57 Modularity ndash Devices Timezone Feature

Name BE

DeviceManagement

Device Timezone

Functions

Chapter

IoT

Goal Implement a Timezone function (devices not in GMT) for all IoT Agents

Description This feature aligns all IoT Agents to be able to configure the timezone of

devices The idea is to have a common specification for all the ADMIN API of

the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST

HTTP API that is similar to the IoT Manager one and it enables Admins to

provision devices services subservices and other configurable elements

58 Modularity ndash Device Life Cicle Feature

Name BE

DeviceManagement

Device Life Cicle

Functions

Chapter

IoT

Goal Implement Device Life Cicle functions (enabledisable in addition to

provisiondelete) for all IoT Agents

Description This feature aligns all IoT Agents to be able to manage devices and other

configurable elements (for instance configure a service to accept only pre-

provisioned devices) The idea is to have a common specification for all the

ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 20: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 20

configurable elements

57 Modularity ndash Devices Timezone Feature

Name BE

DeviceManagement

Device Timezone

Functions

Chapter

IoT

Goal Implement a Timezone function (devices not in GMT) for all IoT Agents

Description This feature aligns all IoT Agents to be able to configure the timezone of

devices The idea is to have a common specification for all the ADMIN API of

the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST

HTTP API that is similar to the IoT Manager one and it enables Admins to

provision devices services subservices and other configurable elements

58 Modularity ndash Device Life Cicle Feature

Name BE

DeviceManagement

Device Life Cicle

Functions

Chapter

IoT

Goal Implement Device Life Cicle functions (enabledisable in addition to

provisiondelete) for all IoT Agents

Description This feature aligns all IoT Agents to be able to manage devices and other

configurable elements (for instance configure a service to accept only pre-

provisioned devices) The idea is to have a common specification for all the

ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 21: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 21

59 Modularity ndash Delete Functions Feature

Name BE

DeviceManagement

Delete Functions

Chapter

IoT

Goal Implement Delete functions (devices services subservices) for all IoT Agents

Description This feature aligns all IoT Agents to be able to delete devices services

subservices and other configurable elements The idea is to have a common

specification for all the ADMIN API of the different IoT Agents

Rationale Provide a common ADMIN API for all IoT Agents The ADMIN API is a REST HTTP

API that is similar to the IoT Manager one and it enables Admins to provision

devices services subservices and other configurable elements

510 Protocols - OneM2M Basic Feature

Name BE

DeviceManagement

OneM2M MCA

protocol

Chapter

IoT

Goal Implement an IoT Agent to support devices connected to OneM2M based IoT

Platforms

Description Support the standard northbound interface MCA as one of the connector needed

to integrate OneM2M In this feature the basic interoperability functions are

provided (observations and commands) The basis will be the software used for

the interoperability demo with OneM2M at ETSI

Rationale The idea behind the BE Device Management GE is to translate IoT Southbound

protocols into NGSI This feature provides a new IoT southbound Protocol

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 22: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 22

511 DevKit ndash SDK Intel Edison Feature

Name BE

DeviceManagement

SDK Intel Edison

Chapter

IoT

Goal Enable the possibility of testing Intel Edison devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on the Intel Edison prototyping board

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

512 DevKit ndash SDK Arduino Feature

Name BE

DeviceManagement

SDK Arduino

Chapter

IoT

Goal Enable the possibility of testing Ardunion devices with FIWARE IoT based

platforms

Description This feature provides IoT makers with the possibility of easily connecting IoT

devices and prototypes In particular this feature enables makers to integrate

devices or gateways based on Arduino prototyping boards

Rationale Provide testing and training tools for any FIWARE IoT platform Additionally

developers may use this as a reference in order to create other components or

run tests with other programming languages andor devices

513 Protocols ndash nodejs Migration Feature

Name BE Migrate all IoT

Agents previously

coded in C++ to

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 23: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 23

nodejs

Goal Simplify Developers and users life by using only one language for all IoT Agents

Description After the experience with C++ and nodejs IoT Agents it seems nodejs ones are fully

functional work well and are easily installed by external users Therefore all IoT

Agents will be provided as nodejs ones

Rationale Having only one language for coding all this enabler components makes the work

more efficient not only in terms of development but also support bug fixing etc

514 Modularity ndash New Github Organization Feature

Name Organize all IoT Agents not

by coding language but by

Devices IoT Protocol in use

Chapter

IoT

Goal IoT Agents repositories will be split by the top IoT protocol in use JSONHTTP UL20

LWM2M etc and not by transport technology (HTTP MQTT CoAP etc)

Description The new organization of IoT Agents Githubs provides a simplified and natural

organization for IoT integrators and novel users They will selec t the repository

dependiong on the top-level protocol and then the IoT Agent will implements several

trasnport protocolsoptions

Rationale The idea behind this features is to provide a unfied simple vision of all IoT Agents

repositories Also manuals support and bug fixing will result more coherent

515 Modularity ndash Improve Operations Feature

Name Unify all IoT Agents Logs

format and change the

per-APi log level

Chapter

IoT

Goal As a result of the experience with IoT Agents we have concluded that logs and their per-

APi level need to be improved

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 24: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 24

Description Logs are used by IoT integrators and expert users in order to trace operational issues

andor potential bugs Unifying logs will make these tasks much simpier and efficent and

chaning the current per-API design will help the identification of actual problems

Rationale Provide a simple efficient and unified log schema for all FIWARE IoT Agents in the

different GITHUB repositories Operation of these components support to external

users and bugfixed will get improved as a result of this feature

516 Modularity ndash IoT Manager Advanced Feature

Name BE Device

Management

IoT Manager

Adavanced

Chapter

IoT

Goal The main goal is to provide a tool to organize and provision the different IoT

Agents in a FIWARE ecosystem

Description In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed) The difference with the previous IoT Manager is mainly new

features related to new supported protocols and an evolved API

Rationale In order to handle several instances of IoT Agents and lots of devices connected

to them a new coordination module is needed This module will run in the

FIWARE cloud and it is not a must for all installations (only when a coordiantion

element is needed)

517 EdgeManagement ndash IoT Infrastructure Feature

Name BE

DeviceManagement

IoT infrastructure

Management

Chapter

IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 25: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 25

Goal Enable a complete IoT Southbound networks coordination and management

from the FIWARE Platform

Description This feature provides IoT operators with the ability of deploying and operating

southbound networks in an SDN-like fashion This way a new feature is

provided in order to help IoT integrators dealing with heterogeneous IoT

networks

Rationale Provide tools to easily operate IoT Networks So far the BE components have

been focussed on NGSI and translating IoT southbound protocols into NGSI on

the other hand this feature adds a new function

518 GeoDescription POIs Integration Feature

Name BE

DeviceManagement

POIs Integration

Chapter

IoT

Goal This features will enable geographical metadata for the IoT devices

Description This feature provides IoT experts with the possibility of geolocating virtual or

existing sensors and actuators to be later represented in 2D3D scenarios

Please check the 2d3D representation GEs for more information

Rationale Improve IoT graphical presentation It provides IoT experts with the possibility

of geolocating virtual or existing sensors and actuators to be later represented

in 2D3D scenarios

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 26: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 26

6 Backend IoT Broker GE

61 Smart Update Handler Feature

Name Smart

Update

Handler

Chapter

IoT

Goal Enable a smarter handling of updates from IoT sources linking updates to

Subsriptions

Description This feature will allow the IoT broker to directly handle updates coming from IoT

sources and to perform a selective forwardinforming to relevant Subscribers It

provides more intelligence for the IoT Broker towards a smarter handling of data

updates from IoT devices

Rationale This feature enhances the functionality of subscription and update handling of

the IoT Broker and widens the usability of the GE

62 History Queries Feature

Name History

Queries

Chapter IoT

Goal Enable that users can query historical data by a specific scope types

Description This feature will enabler users to ask not only for the most recent value of

attributes but for past attribute values in a given time interval The realization of

this feature includes the definition of a specific scope type the definition of a time-

stamp attribute value of metadata as well as the realization of the needed

database functionality

Rationale This feature has been requested by commercial use cases who use the IoT Broker

GE as a middleware component These uses cases provide a graphical dashboard

where users can display statistics of past attribute values

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 27: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 27

63 Advanced Queries Feature

Name IoT

Broker

Advances

Queries

Chapter

IoT

Goal Increase the usability of the query interface of the IoT Broker

Description Increase the expressiveness of the query and subscription interface to enable

quality of information requirements in queries

Decrease the number of unnecessary data requests by means of caching

mechanisms intelligent data source selection policies and data re-use This

feature will further decouple the incoming information requests from the

outgoing requests of the IoT Broker

Rationale Enhance the IoT Broker interfaces such that the advanced functionality becomes

available to users who are deploying advanced IoT scenarios and orchestrate the

IoT behavior more smartly in the sense that not every single query unneccessarily

triggers the whole IoT subsystem

64 Interface NGSIv2 Feature

Name IoT Broker

NGSIv2

harmonization

Chapter

IoT

Goal Increase the interoperability of the query interface of the IoT Broker

Description FIWARE work resulted in an enrichment of the feature of the NGSI interface The

scope of the enriched use is varying from GE to GE To achieve a common

understanding and way of use of all added features a joint discussion inside

FICORE accross chapters or via an ETSI ISG is planned Harmonization of the

implmented interface to the agreement is the goal towards a final release of the

GE

Rationale Harmonize the interface protocol implementation with an to be agreed

specification of NGSIv2 Work will be closely related to til NGSIv2 procedure

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 28: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 28

7 Backend IoT Discovery GE

71 Interface Epic

Name Interface Chapter IoT

Goal Provide alternative application layer interfaces for supporting devices with different

capabilities with a with a variety of data representation formats

Description A variety of devices are expected to interact with IoT Discovery especially those that

are resource-constrained Therefore application layer interfaces that cater to this

should be exposed such as CoAP Different representations of data will to be

supported that cater to developers preferences and application needs For the

semantic module a set of formats are supported but with the emergence of JSON-

LD and increasing popularity this will also need to supported For the NGSI-9 server

module the descriptions were first represented in XML The NGSI-9 server will be

extended to support also JSON representation of NGSI Clients should be able to

send an NGSI request in XML or JSON and receive the response also either in XML or

JSON depending on what they specify in the request header

Rationale Currently a RESTful interface is provided over HTTP for both modules of IoT

Discovery But to enable constrained IoT agents such as gateways and devices to be

able to efficiently interact with IoT Discovery other interfaces that cater to

resource-limited devices will need to be supported Also other formats have

become popular among developers due to their simplicity and clarity JSON is good

example of this Therefore it is important that more simpler formats are supported

by the GE

72 Interoperability Epic

Name Interoperability Chapter IoT

Goal The goal is to enhance the interoperability of IoT descriptions with other

datametadata sources and also to validate registrations so that they comply with

its respective information model

Description By bridging non-semantic NGSI descriptions with linked-open data descriptions we

can increase the chance of interoperability between properties of an IoT description

registered via NGSI clients in the IoT Discovery and other linked open datasets that

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 29: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 29

are available on the Web It is important that IoT Discovery provide support for that

will validate Descriptions based on their respective information model ontologies

Upon registration the submitted description will be validated against pre-approved

ontologies that directly related to IoT or is an essential ontology that provides more

information about a property

Rationale One of the aims of linked open data is to enhance the interoperability between

different sources of data whereby their There can be users who want to interact

with the FIWARE framework using semantic web capabilities The main interface in

the IoT Chapter is NGSI which is non-semantic The repository in IoT Discovery

should only be used for IoT descriptions that follow specific ontologies that are

related to IoT This will ensure that the repository is not used for registering

triplesmodels that have no relation to an IoT information model ontology

73 Repository Epic

Name Storage Chapter IoT

Goal The goal is to address easier setup for data stores and more efficient access to data

Description IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup Iot Discovery will ease

installation by automating the steps for installation IoT Discovery will also address

the distribution of repositories for more efficient access to the descriptions

Rationale IoT Discovery needs to address certain aspects of storage particularly distribution

federation of instances and ease of installation and setup

74 Repository - NGSI9 GeoLocation Feature

Name IoT

Discovery

Ngsi-9

GeoLocation

Chapter

IoT

Goal To allow users to discover context entities based on geolocation

Description The feature will enable users to discover context entities based on their

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 30: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 30

location A discovery request would specify the area of interest in the form of a

geometrical shape as either a circle rectangle or polygon

Rationale Location is a very important criteria for context consumers and is a common

requirement for many applications It will allow results to be more relevant to

what the consumer requires

75 Repository ndash Dataset Generator Feature

Name Dataset

Generator

Chapter IoT

Goal extend the API to provide a dataset generator for testing and experimentation

Description the API for the Linked-data platform Sense2Web will be evolved to provide the

means of generating a sample dataset of registrations This will allows users to

test the load on the GE and also be able to conduct sample experiments

Rationale In order to improve the reliability of the GE a means of testing its resilience is

needed

76 Interface ndash Semantic RegApiv2 Feature

Name Linked-

data

platform

API v2

Chapter

IoT

Goal evolve the API for the Linked-data platform Sense2Web for easier registration

and discovery

Description the API for the Linked-data platform Sense2Web will be evolved for simpler

registration and discovery Several issues have been identified to make the API

more RESTful such as enabling description URIs for entities to be

dereferenceable

Rationale Based on feedback the API can be more RESTful by allowing clients to negotiate

the response media type in the header

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 31: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 31

77 Interface - NGSIv2 Feature

Name NGSI

v2

Chapter IoT

Goal implement the next version of NGSI (v2)

Description the feature will involve the implementation of the next version of NGSI (v2)

Rationale The API is evolving to a more user-friendly interface and will possibly provide

more semantics to the NGSI descriptions and hence towards interoperability

78 Repository - NGSI9 On-Document Store Feature

Name NGSI

persistence

Chapter IoT

Goal replace object store for the NGSI server to a document store

Description The feature will involve replacing the current object store for the NGSI context

entities and subscriptions to a document store This will require changing the

query mechanisms already used in the server

Rationale The embedded object store provided in previous releases provides a quick

method for storing NGSI registration and subscriptions Although to enhance

reliability the store should be able to scale better

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 32: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 32

8 IoT Data Edge Consolidation GE

81 Local Storage Epic

Name Local

Storage

Chapter IoT

Goal The goal is to provide a way to store a reduced set of raw or CEP-processed data

in a local database

Description This epic takes care of local data storage in micro-database This last is part of

gateways sensors and devices no matter if they are wired or wireless The

storage will be configurable in size regarding the number of storable events

Rationale In order to avoid potential connectivity loss and to limit the number of

synchronizations for battery constrained devices a local data cache is necessary

82 DataEdge Cepheus Broker Epic

Name Broker Chapter IoT

Goal The goal is to develop a light broker that is a NGSI forwarding-only

Description Cepheus-Broker is a NGSI lightweight broker Light means only a subset of NGSI

operations are supported

Goal

forward NGSI Context Entities between Agents and remote brokers

handle NGSI10 pubsub feature

operate at the gateway level (runs on Raspberry Pi)

Rationale The Cepheus-Broker is a NGSI lightweight broker This keeps the

implementation simple and sufficient for the use cases handled by the NGSI

gateway

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 33: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 33

83 Common Data Model Epic

Name CommonDataModel Chapter IoT

Goal The goal is to provide a common data model for data exchange between generic

enablers

Description The Data Handling GE will implement a common NGSI data model as an

intermediate language that will be understood by surrounding generic enablers

Only a partial NGSI implementation is expected from Esper4FastData because it is

not its role to be exhaustive regarding this OMA standard

Rationale Data format is an important issue regarding the frequent lack of compatibility

between various software The capability to describe entities in a common way

among GEs and to subscribe to entity updates is also an important feature

84 DataEdge Cepheus CEP Epic

Name Complex

Event

Processing

Chapter

IoT

Goal To process filter and merge data at device gateway or IoT Resources level

Description This epic describes the Complex Event Processing topic as a whole It is

subdivised into fine grained features that describe each defined CEP

funtionnality This epic will be implemented in CEP Engine component

Rationale Complex Event Processing is at the core the Esper4FastData GEi It encompasses

the actual event processing the CEP rule language and the event type

descriptions

85 Manager Epic

Name Manager Chapter IoT

Goal The goal is to provide a configuration for Cepheus

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 34: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 34

Description The configuration is a simple JSON object containing the complete description of

the behavior of the CEP engine (a set of EPL statements) and the mapping

between the NGSI Context Entities and CEP Events

Rationale Cepheus must know the entities that have been registered in the cloud

86 DataEdge Cepheus NGSIv2 Epic

Name IoT

DataEdge-

Cepheus

nGSI V2

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V2

Description This allows the broker and the CEP to communicate in NGSI V2 This allows

to publish NGSI V2 java library This allows to interface with Iot Agent and

Orion in NGSI V2

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V2

NGSI v2 is more simply than V1

87 DataEdge Cepheus NGSIv1Epic

Name IoT

DataEdge-

Cepheus

NGSI V1

Chapter

IoT

Goal allows the broker and the CEP to communicate in NGSI V1

Description This allows the broker and the CEP to communicate in NGSI V1 This allows

to publish NGSI V1 java library This allows to interface with Iot Agent and

Orion in NGSI V1

Rationale This Epic will allow to interface Cepheus with Iot Agent and Orion in NGSI V1

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 35: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 35

The formats of the NGSI v1 are xml and json

88 DataEdge Cepheus NGSI9 Epic

Name IoT

DataEdge-

Cepheus

NGSI9

Chapter

IoT

Goal allows the broker to forward NGSI9 operations to the Remote Broker

Description This allows the broker to forward NGSI9 operations to the Remote Broker

Theses operations will implemented in the Java library NGSI2 For the moment

we dont need of theses operations But in the future maybe for some use-case

we need theses operations

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

89 DataEdge Cepheus GUI Epic

Name Gui Chapter IoT

Goal Remotely manage CEP rules and Broker configuration in a distributed Cepheus

fleet thanks to a graphic user interface using boxes and wires

Description this Epic will provide a user interface to manage rules definition for rules applied

on multiple gateways This Epic will allow to provide a user interface to manage

the configuration of the Cepheus Broker

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file for the Broker ans the

CEP

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 36: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 36

810 DataEdge Cepheus Broker ndash Persistent PubSub Feature

Name IoT

DataEdge-

Cepheus

Broker

Persistent

pubsub

Chapter

IoT

Goal To allow broker to persist the subscriptions and the registrations

Description The subscriptions and the registrations are persisted even if the broker crashs

They are persisted in Sqlite database The Sqlite binary is embedded in the

cepheus-broker software The admin can configure the url of database by

using the property springdatasourceurl By default its value is

$javaiotmpdir-tmpcepheus-brokerdb

Rationale The subscriptions and the registrations are persisted even if the broker crashs

The LocalStorage is important for the robustness of the broker

811 Common Data Model - NGSIV2 Geoloc Timestamp Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI V2 Geoloc and

Timestamp

Chapter

IoT

Goal Add support for date and geopoint type to attributes and metadata

Description Add support for date and geopoint type to attributes and metadata

Rationale The CEP handle date and geopoint types

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 37: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 37

812 Data Edge Cepheus Broker ndash Remote Broker Filter Feature

Name IoT

DataEdgeConsolidation

Broker Filter

UpdateContext

Chapter

IoT

Goal Add option to disable forwarding or filter of updateContext requests to the

remote broker

Description Currently all updateContext request comming from devices are forwarded to the

remote broker by Cepheus-Broker by defaultWe might want to prevent or filter

the updateContext requests beeing sent to a remote broker to let the Cepheus-

CEP component forward it (using more complex transformations like rate

limiting)

Rationale With the filtering of the updateContext to the Remote Broker the broker of the

Cepheus limits the network traffic this feature improve the throughput

813 Complex Event Processing ndash Complex Type Feature

Name IoT DataEdgeConsolidation

ComplexEventProcessing Complex Type

Chapter IoT

Goal allows to use complex type of attribut in the cep statement

Description This allows to support complex values extraction from Context Entities

updates with jsonpath expression

Rationale Orion and Iot Agent handle complex type of attribut

814 Data Edge Cepheus CEP ndash MultiTenant Feature

Name IoT

DataEdge-

Cepheus

Chapter IoT

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 38: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 38

CEP

Multi-

Tenant

Goal allows to the CEP to support Multi-tenant The multi-tenant is an architecture

that allow a single instance of a software runs on a server and serves multiple

tenants

Description A tenant is a group of users who share a common access with specific privileges

to the software instance CEP is designed to provide every tenant a dedicated

share of the instance including its data configuration user management tenant

individual functionality and non-functional properties

Rationale With the support of the multi tenancy the CEP runs on only single instance This

feature allows for better profitability

815 Data Edge Cepheus GUI ndash Cep Configuration Feature

Name CEP

Rules

Designer

for a

multi

gateways

system

Chapter

IoT

Goal Remotely manage CEP rules in a distributed EspR4FastData fleet thanks to a

graphic user interface using boxes and wires

Description this feature will provide a user interface to manage rules definition for rules

applied on multiple gateways This interface will allow to configure also the

all entities In or Out used by the statement of the complex event processing

Rationale User interface to design rules in a multi gateways environment Provides an

ergonomic interface instead of the json configuration file

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 39: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 39

816 Data Edge Cepheus - NGSIv2 Basic Feature

Name IoT DataEdge-

Cepheus NGSI V2

Basic

Chapter

IoT

Goal allows to publish NGSI V2 java library This library contains basic operations

Description This allows to create and publish NGSI V2 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V2 The specifications are under httptelefonicaidgithubiofiware-

orionapiv2

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V2 This feature help the java projects

817 Data Edge Cepheus NGSIv1 REST Feature

Name IoT DataEdge-

Cepheus NGSI V1

REST

Chapter

IoT

Goal allows to publish REST NGSI V1 java library This library contains REST operations

Description This allows to create and publish NGSI V1 java library This library will used by

the Broker component and the other projects may also use it to implement NGSI

V1 The specifications are under httptelefonicaidgithubiofiware-

orionapiv1

Rationale This feature allows to interface all Fiware projects with Iot Agent and Orion in

NGSI V1 This feature help the java projects

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 40: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 40

818 Data Edge Cepheus CEP ndash API Monitoring Feature

Name IoT DataEdge-

Cepheus CEP

APIMonitoring

Chapter

IoT

Goal allows to monitor the CEP via an API The information to be monitored are of

two forms either they are run information (eg JVM informations) or when

they are on the informaitons build (eg git informations)

Description The information to be monitored are of two forms either they are run

information (eg JVM informations) or when they are on the informaitons build

(eg git informations) With the API We dont need to access to the machine

Rationale The monitoring of the CEP allows to see informations during the run via an API

We dont need to access to the machine

819 Data Edge Cepheus NGSI9 - Operations Feature

Name IoT

DataEdge-

Cepheus

NGSI9

Operations

Chapter

IoT

Goal Add the NGSI9 operation into the java library NGSI2 This feature allows the

broker to forward NGSI9 operations

Description Now the Broker of the Cepheus is limited This feature will implement the NGSI9

operations into the java library NGSI2 This feature will implement the forwarding

of the NGSI9 operations to the Remote Broker Now we dont see the need to

implement the NGSI9 If a customer asks us to forwarders operations we will

implement this feature For now this feature is pending

Rationale Now the Broker of the Cepheus is limited The Broker of Cepheus will be full

compliant NGSI9 For now no customer asked this development

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically

Page 41: Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a constant evolution of the roadmap and FIWARE strives to keep it up to date, accurately

Future Internet Core Platform

D1472 FIWARE Technical Roadmap Page 41

820 Data Edge Cepheus CEP ndash NGSI Configuration Feature

Name IoT DataEdgeConsolidation

CommonDataModel NGSI

Configuration

Chapter

IoT

Goal allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Description allows the CEP to store and retrieve the CEP configuration from an NGSI

entity stored on a remote broker (subscribenotify)

Rationale allowing configuration dynamically