top of page

Platform Ambition

The envisaged platform had several requirements, components & features that were not available in a single solution (nor as interoperable separate components) that allowed profound interaction between cities, nor (automated) testing and validation of -related services. Bidders should take into account the design and development of an open platform and its ability to support (externally developed) IoE service components that can be tested and validated in (semi-) automated ways. This translates to the following characteristics for such a platform:





Support City2City interoperability and portability of services and solutions


  • Interface with existing city solutions or solution components through standard APIs

  • Adhere to standards and principles of reusability amongst cities and 3rd parties

  • Compatible with any existing city infrastructure anywhere in Europe



  • Ability to integrate complex data analytics engines and self-learning algorithms based on divergent data-sets of various sources and quality, including both commercial and open source data analytics engines

  • Provide easy access to real-time and non-real-time open data by directly tying this data into the operational infrastructure of a city, allowing third parties to consume and build on top of it.

  • Allow for data-driven innovation



  • Build a (micro-)service architecture: designing platform components as suites of independently deployable integrated services

  • Allow for third party service components development that further enhance the platform

  • Allow third parties to feed the open data repositories



  • Provide each individual user digital access to data, services and content in the most personalized and relevant way

  • Enable and encourage third parties to develop user-centric applications and services

  • Enable the city to be a trusted party, providing state-of-the-art security to safeguard the privacy of citizens



  • Be open and community-based, open source, encouraging anyone to participate

  • Be a (digital) breeding ground for creatives and start-ups

  • Provide tools and methods to support open innovation and co-creation

Large-Scale Testing


  • Include or support testing / validation processes and tools; a systematic process to pilot and measure the impact of any IoE applications in any domain of the city

  • Connect to existing IoE and urban living lab experimentation environments

  • Include tools that measure various impacts of the platform itself (economic, technical, societal), e.g. measurement against (common) KPIs

  • Support simultaneous and parallel testing in different cities

Functional Characteristics




De-coupled and distributed components


  • The architecture must be “pluggable” and components easily replaceable with minimum impact

  • Decoupled components with clear responsibilities and minimal dependencies

  • Distributed components for efficiency & scaling



  • Use of publically accepted 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.)

  • Communication between components via API’s



  • The system must be highly scalable to support today’s and future streams of data.Dynamic scaling (horizontally and vertically)

Legacy compatability and heterogenous landscape


  • Technologies and protocols within the IoE market will continue to change rapidly. The platform must be able to cope with both new and legacy components and handle different versions of the components. Idem for protocols: impact of adding new protocols must be minimal.

Resilience to failure & robustness


  • Technologies in the IoE market are relatively new and evolving quickly. A lot of different types of components from different actors will be in play in the platform. Failure of components and communication will be inevitable, therefore the architecture must be especially resilient. The architecture must be able to absorb the blows and be self-healing.



  • The data and information in the platform must be provided and consumed by open protocols and clear agreements so new components can access the information easily. API’s should be easily discovered and easily understood so new application integrators can use them easily.

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



  • 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 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



  • 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 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 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



  • (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.



bottom of page