Fi-WARE IoTArchitecture Carlos Ralli Ucendo (@carlosralli). Architecture Week.Madrid, April 3rd 2013 http://www.fi-ware.eu http://www.fi-ppp.eu
Warning, we are updating IoT Wiki-docs … … but Only until April 20th
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. Proprietary Sensor FIWARE DATA/CONTEXT BigData, PubSub, CEP FIWARE IoT Back-end Devices Proprietary Gateway Meshed IP WSN (ETSI M2M) INTERNET or Intranet Client APP Devices Things FIWARE IoT Gateway (Technicolor GW, Open HW, etc.)
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.Manas 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 • Implementation: Telefonica ETSI M2M mId
Architecture: BE IoT Broker Enhanced support for discoveringContext Providers • Maintains Information about • available Entity Information • Context Providers • Associations Handles data Requestsand organizes Information Flow FI-WARE Publish/Subscribe C.Broker GE registration information requests* DiscoveryEngine (USurrey) Configuration Management(Telefonica) IoT Broker (NEC) availability requests* Geo-Discovery(NEC, IoT-A) informationrequests* registration GWData Handling (Orange) Discovery ofEntities basedon geographicareas Backend Device Management(Telefonica) • Implementation: NEC
Architecture: BE IoT Configuration Man. context producers NGSI9 registerContext discoverContextAvailability subscribeContextAvailability updateContextAvailabilitySubscription unsubscribeContextAvailability <convenienceoperations> polling dispatching Storage Tier requestprocessing creation/activation NGSI9 <notifyContextAvailability> onintervalnotification garbagecollection • Implementations: Telefonica,UoS.
Example: joint demo with OutSmart Santander Proof of Concept Street Lighting Management
Example: joint demo with OutSmart (II) CEP Big Data OUTSMART APPS • - In the beginning, there are not so much Gateway domain GEs. Pub/Sub JSON BE DEV MANAGER IoT AGENT IDAS API REST • IDAS is totally a Backend component. It does not provide any gateway level sw components. DEV HDL (GW) SensorML/O&M (HTTP POST) Metada Preprocesor (UC implementation) .txt with daily consumption (Active Power, Reactive Power) • Writes Data • Reads Data Writes Data (Illuminance, Presence, Battery) Wifi, 3G AMMS (2) [EON] SQL DDBB [3rd Party] GW (2) • Writes Data (This is the current level) • Reads Data (Which Level should I have?) GPRS Digimesh Light sensors Radars Power Controllers (1) [Ayto]
Thanks !! http://www.fi-ppp.eu