Fi-WARE IoT Architecture Carlos Ralli Ucendo Architecture Week. Madrid, April 3 rd 2013

Warning, we are updating IoT Wiki-docs … … but Only until April 20 th

Fi-WARE IoT – Goals & Concepts -Open approach. Vertical IoT applications, heterogeneous M2M protocols. -Things abstraction vs standalone devices. -Notifications via NGSI to easily plug to Fi-WARE Data/Context GEs (PubSubCB). -Mandatory Backend, Optional Gateway. INTERNET or Intranet Client APP Devices Meshed IP WSN (ETSI M2M) FIWARE IoT Back-end FIWARE IoT Gateway (Technicolor GW, Open HW, etc.) FIWARE DATA/CONTEXT BigData, PubSub, CEP Proprietary Gateway Proprietary Sensor Devices Things

Architecture – Previously …

Architecture – Update. Release 2.3

Architecture – Main Changes All changes will be reflected in our Wiki & D2.3.2 Architecture Deliverable (April 12nd). -Overall, we’ve simplified the architecture & reduced the number of GEs. -No functionalities are dropped, but included in relevant GEs. -Security: -Backend: Northbound interfaces to be secured with FI-WARE Security Single sign-on. -Gateway: TBD for Release 3 (features of GW Dev Man). -Advanced Connectivity: -Backend: Most functions are included in the BE Dev Management. -Gateway: TBD for Release 3 (features of GW Dev Man). -Discovery Engine & Geo-Discovery: -They both have been included in the Conf.Man as optional features. -Optional Gateway & GW Device Management GE: -GW Dev Man is planned for R2.3. In the meanwhile or constrained gateways, Protocol Adapter will speak NGSI10 with Data Handling to route events. -BE Dev Man supports SensorML over POST HTTP whenever a GW is not implemented.

Architecture: GW Device Management Implementation: Fraunhofer

Architecture: GW Data Handling Implementation: Orange

Architecture: GW Data Handling (II) A more lightweight option is available for constrained/limited Gateways. Only CEP and NGSI interfaces are implemented. Storage is considered an optional feature in this GE and thus not implemented in this case. Implementation: ATOS

Architecture: GW Protocol Adapter Implementation: Telecom Italia

Architecture: BE Device Manager REST-API ADMIN REST-API NGSI9-10 ETSI M2M mId Implementation: Telefonica

Architecture: BE IoT Broker IoT Broker (NEC) IoT Broker (NEC) Configuration Management (Telefonica) Configuration Management (Telefonica) Discovery Engine (USurrey) Geo-Discovery (NEC, IoT-A) Maintains Information about -available Entity Information -Context Providers -Associations Enhanced support for discovering Context Providers Discovery of Entities based on geographic areas availability requests* FI-WARE Publish/Subscribe C.Broker GE FI-WARE Publish/Subscribe C.Broker GE information requests* GW Data Handling (Orange) GW Data Handling (Orange) registration Handles data Requests and organizes Information Flow Backend Device Management (Telefonica) Implementation: NEC

Architecture: BE IoT Configuration Man. dispatching Storage Tier Storage Tier request processing oninterval notification registerContext discoverContextAvailability subscribeContextAvailability updateContextAvailabilitySubscription unsubscribeContextAvailability NGSI9 NGSI9 polling garbage collection creation/activation context producers Implementations: Telefonica, UoS.

Example: joint demo with OutSmart Santander Proof of Concept Street Lighting Management

Example: joint demo with OutSmart (II) (1)Writes Data (This is the current level) (2)Reads Data (Which Level should I have?) GPRS IDAS API REST DEV HDL (GW) Metada Preprocesor (UC implementation) AMMS (2) [EON] Radars Power Controllers (1) [Ayto] SensorML/O&M (HTTP POST).txt with daily consumption (Active Power, Reactive Power) Writes Data (Illuminance, Presence, Battery) Wifi, 3G GW (2) SQL DDBB [3rd Party] Digimesh Light sensors (1)Writes Data (2)Reads Data OUTSMART APPS JSON Pub/Sub CEP Big Data - In the beginning, there are not so much Gateway domain GEs. IDAS is totally a Backend component. It does not provide any gateway level sw components. IoT AGENT BE DEV MANAGER

15 Thanks !!