Smart city and data

Key aspects of the strategic development of smart cities include concept and methodologies that enable the city to be unified. And this is particularly true with data. Prague as a whole consists of 57 city districts, municipal companies, contributory organisations, the city council and many other organisations, and each can acquire their own solution that can be categorised as a smart city solution. And these solutions, besides serving their primary purpose, each generate a variety of data, which is many cases has value only when connected to and supplemented by other data. To enable data to be connected to the Data Platform and worked with at the citywide level it is crucial that the client itself has primary access to the raw data. However, this often tends to be overlook during the course of tenders, and supplies often only offer the option of a pre-defined view of the relevant data, and not access to the source data. We realise that in many cases it is not technically feasible for the smart city solution client to process such data directly. And this is why we offer this option. For the client it has the advantage that there is no need for any special visualization and reporting tools and, whenever the client wants to change something, it does not have to generate more and more orders and contracts. For us it has the advantage that we will have more data available to us, enabling us to manage the city better and more efficiently. 

Below we present the findings and specifications we have acquired so far, which may be incorporated directly into the tender and subsequently into the contract with the supplier. The specifications are given with a view to existing solutions and experience; however, the data structure may be expanded (the addition of sensors, etc.) to suit the options available with the specific solutions and the requisite functionality. If it proves necessary to create a new specification, the Data Platform team is ready to assist, just as if any changes need to be made in line with the client’s specific requirements. 

If you have experience that you would like to see included in the examples of good practice listed below, we will be glad to hear from you. We will pass your recommendations on the relevant stakeholders. 

General requirements for contractual and tender documentation

Ownership of data

It is crucial that, besides having access to data, the client also has the right to handle the data as it needs to. It is advisable to include a provision in the contract that states that the client is the “owner of the data”, as regards (i) unrestricted access to data, (ii) the absence of any conditions that would restrict the client’s ability to handle the data, and (iii) restrictions on the supplier’s rights to handle data for purposes other than the performance of the contractual relationship. The client should also reserve the right to publish the collected data in the form of open data as defined by Section 3(11) of Act No. 106/1999 Coll., on free access to information. In accordance with Government Resolution No. 889/2015 Coll., the client should also request that each new information system be open data ready.

Legislative changes

The contract should contain provisions that oblige the supplier to ensure that the solution supplied is always in compliance with the currently applicable legislation, such as in the case of mandatory reporting to Prague City Hall.

Anti Vendor Lock-In

One frequently overlooked aspect of contracts, one which makes the subsequent operation of ICT projects considerably more expensive, is a provision preventing a Vendor Lock-in, i.e. a situation where inappropriately set rights forces the client to be dependent on the supplier. Related to this are provisions concerning copyright relations, the management and provision of documentation and source code, data migration, etc.

If data is obtained from an IoT device, it is advisable to request a direct connection to that device via wireless technology in accordance with the contractor’s proposal (E.g. LoRa, Sigfox, GSM, etc.), including the provision of documentation; this requirement will ensure control of the device and the ability to download data from it without the need to pay fees for the supplier’s infrastructure.

SLA requirements

An integral part of the contractual documentation is the Service Level Agreement (SLA), i.e. an “operation and maintenance agreement”. It is essential to stipulate penalties in the event that the interface is unavailable; if the supplier is not subject to a penalty imposed by the client (city district), availability cannot be forced in any other way, which may result in failure to comply with the cooperation agreement for the purpose of drawing funds from the smart cities reserve. We consider that data should be available from the interface for at least 99.5 % of the month, meaning that data can be unavailable for 3.6 hours per month. The structure and content of the SLA are described in detail in, for example, the ITIL set of best practices.

Example formulation

„Service available for 99.5% of the month within the scope of the SLA with the option to issue a report on compliance with the SLA (results achieved) during the previous month.
If the maximum SLA value as specified in the previous paragraph is not assured, due to failure to comply with the SLA during the given month the client has the right to claim a 5 % discount on the monthly price of the service, applicable in the following month.“

Data access requirements and examples for individual areas

Presented below are the conditions required to enable data to be integrated into the City of Prague Data Platform; the specification is a general one and is suitable if you are not considering integration into the City of Prague Data Platform. See below for specific examples of what can be monitored. 

General specifications of interface

It is crucial to specify data access in the form of an API. The interface should enable current data to be exported via the API interface based on the REST philosophy, implemented over a secure HTTPS protocol (including the return of status codes); it should contain standard authentication (OAuth, login, or token), data output in JSON or XML format, complete API documentation, interface versioning.

The standard solution is an interface from which the client can download (pull) data. If the status of the equipment changes, i.e. if a bin is full or if a vehicle parks over a sensor, communication should run in the other direction, i.e. the supplier’s solution should send notification in the pre-defined structure of a data sentence (push). The specific schematics of that data sentence will be designed together with the client during the process of creating the contractual documentation and later with the supplier and the ICT Operator, in order to be compatible with the Data Platform interface. 

It should be specified that data from the interface must be available for at least 99.5 % of the month.

Indicators/data from the equipment will be averaged out for the given time period (interval).

Intelligent monitoring system

Data will be provided from the equipment/system, enabling events to be detected.

Data is divided up into static information, to be provided after the system has been launched, and, in the event of any change in the position of the equipment, real-time (up-to-date) data. The minimum scope of data required is specified below. 

Static information

  • unique equipment identifier;
  • timestamp of change to static data;
  • position of equipment in GPS format;
  • position of equipment as text description;
  • description/list of functions, e.g.: night vision, recognition: weapons, suspicious objects, crowds, theft, traffic offences; in the greatest possible detail, see brief description of project.

Real-time data

Real-time (up-to-date) event data with a maximum periodicity interval of 5 minutes (all events in the given 5 minutes) structured as follows

  • unique equipment identifier;
  • timestamp;
  • Event type, see list of functions

Statistická real-time data

Statistical real-time (up-to-date) data with a maximum periodicity interval of 5 minutes, structured as follows:

  • Unique equipment identifier;
    timestamp;
  • Average number of people in the location being monitored.
  • Average number of vehicles in the location being monitored.
  • Average number of cars in the location being monitored (if the system is able to differentiate).
  • Average number of cargo vehicles in the location being monitored (if the system is able to differentiate).
  • Average number of cyclists in the location being monitored (if the system is able to differentiate).

The data access interface should provide historical data with at least a 7-day history, in the same structure as the real-time data. 

Parking on the basis of mobile operator data

Data is divided up into static information, to be provided after the system has been launched, and, if any change is made to the section or sections, real-time (up-to-date) data. The minimum scope of data required is specified below.

Static information

  • unique section identifier;
  • timestamp of change to section capacity;
  • Parking space capacity in the given section (with 80 % accuracy, +-10 % standard deviation).

Real-time data

Real-time (up-to-date) data with a maximum periodicity interval of 5 minutes, structured as follows:

  • unique section identifier;
  • timestamp;
  • GeoJSON section polygon type pursuant to (RFC 7946);
  • Number of occupied parking spaces in the given section (with 80 % accuracy, +-10 % standard deviation).

The access interface will also provide historical data with at least a 7-day history, in the same structure as the real-time data. Access to historical data will be used by the client or a third party only if the real-time data cannot be downloaded. 

Smart benches

Data is divided up into static information, to be provided upon installation and, if the equipment is moved, real-time (up-to-date) data. The minimum scope of data required is specified below. 

Static information

  • unique equipment identifier;
  • installation date;
  • position of equipment in GPS format.
  • types and manufacturers of sensors for measured variables, including the unit and installation height above the ground, e.g.: (humidity, percentage, Honeywell HIH4030, 200cm ; temperature, Celsius, STMicroelectronics LPS25H, 200cm; ….)

Real-time data

Current data with a maximum periodicity interval of ten minutes to functionalities that devices provide (e.g. temperature, atmosphere quality, humidity, etc.), in the following structure:

  • Unique device identifier;
  • Timestamp;
  • Numbers of users connected to WIFI;
  • Indicator of ongoing charging through USB port(s);
  • Data from individual sensors.

Real-time (up-to-date) data with a maximum periodicity interval of 10 minutes on the functions provided by the equipment (e.g. temperature, air quality, humidity, etc.), structured as follows:

Smart lighting

Data on the individual pieces of equipment as static information, to be provided upon installation and, if the equipment is moved, real-time (up-to-date) data. 

Static information

  • unique equipment identifier;
  • installation date;
  • position of equipment in GPS format.

Real-time data

Real-time (up-to-date) data with a maximum periodicity interval of 10 minutes on the functions provided by the equipment (e.g. temperature, air quality, humidity, etc.), structured as follows:

  • unique equipment identifier;
  • timestamp;
  • data from individual sensors or, where applicable, from the charging station (if included).

The access interface will also provide historical data with at least a 14-day history, in the same structure as the real-time data. Access to historical data will be used by the client or a third party only if the real-time data cannot be downloaded. 

Smart crossing

Data on the individual pieces of equipment as static information, to be provided upon installation, and real-time (up-to-date) data.  The minimum scope of data required is specified below. 

Static information

  • unique equipment identifier;
  • installation date;
  • position of equipment in GPS format.

Real-time data

Real-time (up-to-date) data with a maximum periodicity interval of 10 minutes on the functions provided by the equipment (e.g. number of pedestrians and drive-throughs, temperature, air quality, humidity, etc.), structured as follows:

  • unique equipment identifier;
  • timestamp;
  • number of pedestrians;
  • number of vehicle drive-throughs;
  • data from individual sensors.

The access interface will also provide historical data with at least a 14-day history, in the same structure as the real-time data. Access to historical data will be used by the client or a third party only if the real-time data cannot be downloaded. 

Compactor bin

Data on the individual pieces of equipment as static information, to be provided upon installation, and real-time (up-to-date) data. The minimum scope of data required is specified below. 

Static information:

  • unique equipment identifier;
  • installation date;
  • position of equipment in GPS format;
  • location (positioning), e.g.: by entrance to park, etc.

Real-time data

Real-time (up-to-date) data with a maximum periodicity interval of 5 minutes on the functions provided by the equipment (fullness, technical condition, etc.), structured as follows:

  • unique equipment identifier;
  • timestamp;
  • fullness in % (at least 2 levels);
  • technical condition;
  • data from individual sensors;
  • location (positioning), e.g.: by entrance to park, etc.

The access interface will also provide historical data with at least a 14-day history, in the same structure as the real-time data. Access to historical data will be used by the client or a third party only if the real-time data cannot be downloaded. 

In order to restrict queries concerning the state of the bin, the supplier and the ICT Operator may agree that the data sentence will be sent via the API structured as real-time data to the Data Platform. The specific schematics of that data sentence will be designed together with the client during the process of creating the contractual documentation and later with the supplier and the ICT Operator.