SELECT4Cities Desired Components

 

An IoE platform contains several components. The following sections illustrate our view of what a future SELECT4Cities platform solution should tackle. This does not exclude future bidders to propose their own set of components. 

 

Communication with “things”

• The platform should be capable of communicating with “everything”. This term is used to refer to the broad interpretation of the term “things”. With “things” we refer to devices/sensors/actuators. With “everything” we additionally refer to other data sources (e.g. feeds, reference data,...).

• Especially with regards to “things” following patterns should be supported:

​

 

 

 

 

 

 

 

 

 

​

 

 

 

 

​

• Communication with IP-Capable devices: Communication bridges, IP-capable sensors. This must be supported by the platform.

  • Protocols can be light weight. Functionalities include: streaming, queuing, request-response

  • Examples are: HTTP, CoAP, STOMP, AMQP, MQTT

  • More traditional protocols can also be supported like SOAP

• Communication with sensors which are not IP-capable (e.g. communication via LoRaWan, bluetooth, zigbee, and Dash7) is not required to be part of the platform.

 

Ingestion of outside data

• Data from external references is a valuable asset for better understanding the stream coming from devices. This data comes from different sources and can be in bulk, on request or streaming (feeds). Examples are government reference data, social media (twitter feeds, facebook feeds)

• The data can be accessed on request (real-time), cached (near-real-time) or stored (batch)

 

Device/Source managment

• Device management allows us to manage all the devices (owned and third party) and helps us in following use-cases:

  • Device provisioning and discovery

  • Device registry and device models

  • Device access management

• Remote controlSource Management allows to manage the different streams of data

  • Registry of sources and source meta-data

  • Source access management

 

Classification

• Streams of devices can be automatically classified

• Examples of classifications are:

  • Sensitivity

  • Source

  • Reliability

• The classification process should run automatically on new streams.

• A reliability classification should be able to classify the new streams and give them a higher classification if they prove to be more reliable

 

Storage of data

• The platform should be able to store large amounts of data with a great variety and a great velocity

• Different types of storages should be possible, so it can handle different use cases (e.g. graph db are great for real-time recommendations, document database can be interesting to store statuses of sensors)

• A data lake should be built to store all the relevant data for future analytics

 

Data abstraction/aggregation

• Data needs to be abstracted (data typing and meta-data) to be understandable and to transfer it to valuable information.

• Aggregation helps in transforming large amounts of data in more understandable formats, it also helps in showing in a clear way how data is interlinked

• Together these algorithms help in better understanding the data and help in creating information from the data

 

Meta-data classification

• Meta-data classification helps in modelling data models, so we can apply them to the different data sets

• The tool helps in discovery of meta-data and applying it to the data

• Meta-data can be retrofitted to the data in the platform

 

Analytics

• Analytics helps (by using abstraction, aggregation & meta-data) in discovering new patterns in data and helps for example in cause-effect analysis

• Inline analytics can use patterns to discover interesting events in the different streams of data and can broadcast these events. For example, detecting a traffic accident

• The detected events can be sent to applications or can be sent to actuators on the field (like signalling boards).

 

Reporting & business logic

• Reporting creates reports on the data in the platform, these reports are both real-time and static. They can be used as a feed for dashboards

• All the information in the platform can be used to run line of business applications

• Search is a specific version of business logic and can help in the discovery of information

 

API

• All the data & information is provided to other application through api’s based on open standards like HTTP, SOAP, REST,...

• In such a way that other companies or users can build apps on top of the platform real-time (and static) information

• The platform allows for apps (like custom algorithms) to intervene in the inline analytics and provide new streams of events based on aggregated and abstracted data

 

Security

• Security is crucial in the platform and has an effect on all the components

• In communication with the sensor we should take into account following security measures:

  • Identification for the sensor (e.g. non-repudiation)

  • Securing the transport of data (prohibiting the eavesdropping of data)

  • Securing the data (prohibiting the changing of data)

• In the platform the following should be taken into account:

  • Access control of all the different resources

  • Auditing of the access (also read) of the different resources

  • Data should be encrypted (privacy data) and only accessible with the right authorisations

 

Privacy

• Privacy is a major concern in IoT & big data cases

• Provide framework and reference implementation of MyData IoT Model

• To protect the privacy of citizens, the following should be taken into account:

  • Is the storing of personal information necessary and fit for purpose

  • Is the access to this information well protected and audited

  • Is personal information encrypted or hashed for everybody who isn’t allowed to see the clear data

  • Can the information be aggregated

  • Can information about a person be linked throughout the platform for statistical purposes nonetheless

 

Visualisation

• (Processed) data should be accessible through API’s, but the platform should also include its own visualisation layer.

• The platform should translate all the IOT data to meaningful information, so a city can base actions on it. This may imply some ability to go deeper into specific data and visualize them separately (compared to zooming in a map, where new details emerge).

• It might be interesting to visualise all IOT-data (from various sources) from the different cities in one tool. Additionally datasets stored in the cloud could be added. Thus the platform would supply one central access/collection point for all cities IOT-data.