Federico Michele Facca - FIWARE Primer - Learn FIWARE in 60 Minutes
Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a...
Transcript of Private Public Partnership Project (PPP)IoT)… · chapter. The agile methodology implies a...
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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