IoT on the Edge presentation, by Dr. G. Privat. Senior Scientist, Orange Labs. 1st FIWARE Summit, Málaga, Dec. 13-15, 2016.

1. IoT on the edge
Dr G. Privat
Senior Scientist, Orange Labs
gilles.privat@orange.com

2. edge
1
FIWARE in the cloud & in the edge
sensor data providers
LPWAN sensors
developers
end users
other data
providers
latency-critical
sensor & actuator
networks
FIWARE
backend
Apps
Operator
platform
LPWA
Network
servers
Equipment
vendor
platform
sensor data providers

3. Smart City platform
4
CKAN
Big Data
Context Broker
Accounting&Payment&Billing
IDM&Auth
Short-term
historic
data
BigData
Processing
Data
Quering/Action,
Publish/Subscr
Open Data
publishing
Real-time
processing
BI
ETL
RULES
DEFINITION
TOOL
OPERATIONA
L
DASHBOARD
KPI GOVERNANCE OPEN DATA PORTALS
Service
orchestrator
Context
Adapters
CEP
IoT Backend
measures /
commands
Sensors Open DataActuators
Media
streams
Real Time
Media
Stream
Processing
City
Services
GIS
Inventory
Specific Enablers
Generic Enablers
IoT Edge
Device
manag
ement
&
abstra
ction

4. Rationale for « edge » processing
 Address envisioned exponential growth in volume of sensor data
 Avoid wasteful use of networks for sending useless or noisy data to
the cloud
 Filter, cleanse, aggregate, consolidate, vet data close to data sources
 Make up for imbalance between upward and downward data flows
7

5. CEP for generic sensor data filtering & fusion
 sensor fusion used to a « black art » sub-domain of signal processing
 CEP offers a simple approach for the most basic types of
• data cleansing
• data selection
• data normalization
• feature extraction
 not the mainstream use of CEP…
 less flexible and powerful than dedicated numeric processing
 yet easily programmable
 can be reconfigured on demand and,possibly, automatically
8

6. Addressing requirements of reactive systems
 beyond those humdrum present-day IoT applications
• mostly monitoring and data collection!
 beyond routine big data, beyond « fast data »!
 accounting for industrial cyber-physical systems applications that
involve control of physical plant
• applications that are “defined by their effect on the physical world”
• time-response is NOT best-effort or part of QoS
• mirroring the state of field systems in order to control them
• no time lag between actual state and state maintained in model
representation
• bounded and deterministic return-trip times between field devices
(sensors and actuators) and platform are mandatory
9

7. Architecture template
for real-time IoT/CPS platform
10

8. Acting upon entities through devices
 IoT devices are acted upon through changes in the state of entites
11
Backend platform
FIWARE APIFIWARE API
GET <Oauth token>
/cityEntities/street1/presenceState
PUT <Oauth token>
/cityEntities/street1/lamps/”OnState”
Edge IoT Applications
Edge platforms
Backend IoT Applications
FIWARE API

9. IoT Data Edge Consolidation IDEC/Cepheus
 core engine derived from ESPER
 rules expressed in EPL (Event Processing Language)
 operates over 2 complementary windows:
• sliding time window
• spatial window (scope)
• limited to « stateless » « along-the flow » processing
• consolidation for
12

10. IDEC/Cepheus
13

11. Distributed FIWARE platform
 beyond « all-cloud » one size-fits-all approaches
 interim solutions before full-fledged « fog » platform ensures
transparent and flexible distribution
• fixed distribution between backend and edge
 edge platfrom could be hosted in :
• operator NG-PoP (Next Generation Points of Presence)
• customer-premises servers (e.g. for smart building, industry compounds)
• LAN gateways
• local embedded servers
□ Cepheus tested on raspberry-pi
14

12. Thank you!
http://fiware.org
Follow @FIWARE on Twitter