DECODE/DEC03 use case

Use Case ID - Use Case title

DEC03 - Sharing sensor data

Owner of Use Case

Stefano Bocconi - DECODE project

Description

Residents of a particular square are concerned about noise generated at night by the clients of the venues in the square. They decide to measure with low-cost sensors the noise level, either inside or outside their residence. To be able to provide a global picture of the situation in the square, users might be willing to share their measurements, but possibly not about particular periods (like during the day) or not the exact location of the sensors.

Moreover, users want to be able to share the data only with particular groups

Requirements

Related functional requirements

• Users must be able to register their sensors to a platform and indicate a sharing policy for the data generated
• Policy must be enforced by platform collecting sensor data.

Component(s)

• A sensor generating noise measurements
• A platform that can register the measurements, and offers options for data sharing in the form of data policies

Types/classes of data involved

• Sensor data
• Policies of data sharing

Actors

• A local community that wants to measure noise pollution in a particular area
• A platform owner that offers data visualisation subject to sharing policies.

Preconditions

• Users have a sensor, want to register it and choose a sharing policy
• Platform offering data sharing and policies

Postconditions

• Noise pollution can be visualised on a map respecting the privacy of the users.

Normal Flow

• User acquires and register a noise sensor with the platform
• User specifies a sharing policy
• Sensor generates data
• Data is filtered on the platform to remove what the user does not wishes to share
• Data is encrypted on the platform so that only particular recipient can see it
• Platform reveals aggregated data for the recipients authorised to see it.

Evaluation of UC and requirements realisation

(e.g. manual, automatically...)

Categories of personal data involved

The following data is only marginally personal (location mostly):

• Attribute stating holder is owner of a sound sensor
• Location of the sensor
• Noise measurement of the sensor (level, time)

No other data such as name, date of birth, etc is necessary.

Data is stored according to the policy chosen by the user and visualised also according to the same policy.

Purposes for personal data handling

The purpose of the processing is to assess the noise level in a neighbourhood (in particular, in a square).

This data can be used to assess whether particular policies have effect in reducing noise pollution for residents.

Different kinds of processing involved

Once the data is sent by the sensor to a platform, before storing it the policy chosen by the user is applied and the data is processed for example to:

• Remove the exact location and substitute with a random point within a radius of the real location
• Remove the timestamp
• Drop data in particular intervals of time, such as during the day.

After storage, the data is visualised on a map.

Data subjects, controllers, processors, and recipients involved

The data subjects are the citizens owners of a sound sensor.

Data controller is the entity running the visualisation platform.

Recipients is every viewer of the visualisation. Again, the data is only marginally personal as it is about sound levels.

Storage & security aspects

Noise level data will likely be kept for a long term in order to support policy making and also citizen science.

Security is responsibility of the platform owner.

All this data is not directly linked to a person, so we can say that it is at least in pseudonymisation form.

Means of legitimation for personal data processing

The data is gathered on the basis of a policy chosen by the user and with its informed consent.