TC10.20 - The Snap4City solution is Interoperable

×

Warning message

  • You can't delete this newsletter because it has not been sent to all its subscribers.
  • You can't delete this newsletter because it has not been sent to all its subscribers.

Test Case Title

TC10.20 - The Snap4City solution is Interoperable

Goal

Communicates with existing and new systems of the cities

Provides mechanisms and tools to perform analytics on combined data, including different device and data sources and streams

Uses accepted and emerging standards and open

Prerequisites

Using a PC or Mobile with a web browser.

The following functionalities are available only for specific Snap4city users with specific privileges.

Expected successful result

The verification of other TCs.

Steps

 

Snap4City is capable to interoperate since it can:

 

Snap4City is capable to interoperate since it can Expose its data and services via:

Interoperability with Heatmaps and WMS

Snap4City is working with Heatmaps and Maps in WMS standard. Heatmaps are saved in terms of points in the Heatmap manger server and automatically produced on the basis of the set colormap, the maps/heatmaps are provided to dashboards in standard WMS by means of a GeoServer.

You can see the difference comparing the heatmaps in the two examples:

 

Other information (may be older)

See Supported Protocols for the full list of supported protocols.

Interoperability can be demonstrated by showing how the solution proposed can be integrated with already in place solutions. See for example the list of Open Source tools from Apache and well known other distributors on which the solution proposed is based. Being based on Apache Hadoop, Phoenix, Hbase, Penthao Kettle, NodeRED, MySQL, Tomcat, DRUPAL, CKAN, etc. the solution is interoperable in principle with many solutions based on the same fundamental tools. Please see on this regard the section about ACPaaS in which a possible integration has been described. The effective interoperability is also shown by providing the effective integration of the solution proposed in different context. The solution proposed is natively integrated in Km4City and thus is proposed for free to all the partners already using the Km4City solution as a simple add on, bringing the IOT exploitation to a next level with respect to the present solution. 

  1. The prototype is able to communicate with existing and new systems of the cities

The Snap4City solution is easily integrated with already in place solutions for the large overage of protocol, see above the list on Q6. This means that the Snap4City solution is capable to exploit the solutions which are in place of the city operators using a range of tools: IOT Brokers, ETL, NodeRED, CKAN.
 
In order to test the satisfactory of this feature it has been already shown in other TCs that:

  1. The prototype provides mechanisms and tools to perform analytics on combined data, including different device and data sources and streams

The Snap4City solution allows Data Analytics processes:

  • defined and executed by using different kind of languages (programming paradigm):
    • Native code processes on VM and scheduled coded in: Java, ETL, R, H2O, C++, Python,
    • ETL processes
    • NodeRED as Snap4City Applications
  • Executed in Containers or independent processes, scheduled by DISCES;
  • call External Services from a large number of languages;
  • call MicroServices coming from the several Snap4City APIs from a large number of languages. For example, specific Blocks for NodeRED and/or for ETL are provided (not yet available)
  • Executed on the basis of Data Driven, via IOT events, via Publish / Subscribe protocol, Snap4City Applications,
  • Executed on demand from other services: Web Portal, ETL, etc. via DISCES
  • Executed programmatically and periodically by DISCES according to different policies.

 
A VM as for Data Analytics and ETL (Data Processing Development Environment) is provided as a specific Snap4City tools. Once an ETL or Data Analytics process is produced it can be uploaded and monitored on the platform by using the ProcessLoader tool on web. Please note that ETL processes can be used to ingest data coming from several protocols and services as described in Q6.
 

  1. The prototype uses accepted and emerging standards and open platforms (e.g. The Open Group IoT standards O-DF, O-MI, AIOTI Architectures suggestions, IOT EIP pre-standardisation work, XML, JSON, SOAP, REST, etc.)

The proposed solution is capable to use well established standards as described in Q6, including potential new standards mentioned in TD2, by means of the solution proposed in Q6. UNIFI DISIT lab is part of the ISO TMP Smart City Standardization group. The EIP is an activity followed by UNIFI DISIT.
The prototype is able to consume services that are provided using open standards as demonstrated in other TC.
The prototype is able to cope with both new and legacy protocols and impact of adding new protocols is minimal, for the coverage of NodeRED+ETL+ORION with respect to a wide selection of protocols.