[Fiware-espoo] Scenarios for the connection to FI-Lab

[Juanjo Hierro]

Hi all,

This is the description of the three scenarios of data integration that we are managing with the several cities connecting to FI-Lab.   I believe you already got the idea from our last confcall but we committed to write down this email which I hope may give more light.   We understand these scenarios may map to Espoo as well.

  We would then need to understand what scenarios yo propose to develop and what kind of example applications you propose to develop based on them.



1.       Published Open Data exploitation.

  This is the most basic scenario that some cities have carried out, usually as a first step that allows them to materialize a "quick win".   Many cities have typically published open data in some of their websites, sometimes using a platform suitable for doing so such as CKAN.   Uploading these open datasets on the FI-WARE BigData enabler (Hadoop-based) instantiated on FI-Lab is the goal in this scenario.

  Activities within this scenario consist in the development of automated processes that connect to the platform used by the city to publish its open datasets (e.g., CKAN).  Such processes will gather, clean up, format and upload the existing open dataset in the BigData generic enabler platform.    This way, developers can run analysis on published data using map-reduce techniques, extracting relevant insights.  Besides this, uploaded data can be queried to build added value applications (e.g., through a Hive connector).

  Check the following example, based on the merge of Malaga city open data of plagues and meteorological information: http://130.206.81.65:8080/plague-tracker/



2.       Access to real-time Open Data exported by systems managing some city service

  Usually, there are systems deployed in cities dealing with management of some city services.   As an example, there may exist a system managing the public bus transportation system (such system may be dealing with programming of buses lines, real-time positioning of buses, allocation of drivers to buses, etc).    Some of these systems manages information that could be rather valuable to export as open data that can be queried in real-time using a standard API.    This is the goal of this scenario.   Following the previous example, it would be valuable that the system exports the geo-location of each bus so that developers can query it in real-time using a standard API.

  This scenario typically implies development of some adapter which can connect to the system managing the relevant data using some sort of (proprietary) interface it exports.   Such adapter would then push the data as an update of the context information managed by a FI-WARE ContextBroker Generic Enabler deployed on FI-Lab, using the NGSI publish/subscribe API the ContextBroker Generic Enabler exports.  This way, developers can access to (near) real time information from municipal systems.

  Note that there may be several city systems, each with its own adapter, sending updates to the same ContextBroker Generic Enabler deployed on FI-Lab.   Indeed, this is one of the real values we want to achieve: applications will be able to subscribe or query to the information coming from the whole set of disparate systems but using the standard NGSI API exported by the Context Broker Generic Enabler.



3.       Generation and processing of data from sensors.

   In some other cases, cities can deploy sensors and it wishes that data exported by those sensors becomes available real-time as open data.    There are two ways to do so.   A first approach would consist in developing an adapter, typically to be run on a sort of gateway device close to the sensors which can connect directly to the ContextBroker.    A second alternative would be to connect with the FI-WARE IoT Backend Device Management Generic Enabler taking advantage of the facilities it provides for efficient communication with devices.   The FI-WARE IoT Backend Device Management Generic Enabler automatically publish gathered data through the Context Broker Generic Enabler which will be the Generic Enabler developers will finally connect their applications.

  Again, since the BigData Generic Enabler is keeping history of data received by the Context Broker, it would be feasible to perform map-reduce analysis on data gathered from sensors.


       4.       Open data extracted from video cameras.

  Video streams captured through video cameras distributed across the city can be processed in real-time using the FI-WARE Stream-Oriented Generic Enabler (Kurento being the open source reference implementation).   This processing may lead to generation of anonymous discrete data that can be publish as open data.

  As an example, video streams captured through video camaras distributed in some streets can be processed in real-time to identify masses of people and then be able to publish whether a given street is "crowded", "normal", "deserted" at each point in time.    This could be valuable to publish Mass location maps, detect masses of people which may require some action, analyze mobility of masses, etc.

  This scenario can be seen as a special case of scenario 2 (in which the system to connect to the Context Broker has in turn be developed using FI-WARE Generic Enablers) or as a special case of scenario 3, in which we have use the combination of a camera plus the application processing the video streams to build a kind of "sensor".    In the previous example, we are kind of building a "sensor of masses"



5.       Summary.

  Of course, there are a number of additional GEs in the platform that can be used by the developers/integrators to exploit that data and help them in the process of building applications but those above are the most commonly used ones.

The picture below represents the three first scenarios (pay attention to the stars).   We hope it can help you to get an idea, although we can explain it in detail in the next confcall.

[cid:part2.09080408.06030601 at tid.es]


Best Regards,


Sergio.



________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-espoo/attachments/20140226/d1080c07/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 130662 bytes
Desc: not available
URL: <https://lists.fiware.org/private/fiware-espoo/attachments/20140226/d1080c07/attachment.png>