d2.1-use cases.pdf

39
FP7-SMARTCITIES-2013 Project number: 609062 http://www.smartie-project.eu/ SMARTIE Deliverable D2.1 Use Cases Editor: Manfred Kopielski (GWS) Dissemination level: (Confidentiality) PU Suggested readers: Other reader groups Version: 1.0 Total number of pages: 39 Keywords: Smart City, scenarios, smart city information centre, traffic, transport, energy Abstract This document describes the initial use cases for the SMARTIE project taken from different thematic areas of a smart city environment. The areas include the energy, transportation and traffic management. The description of the use cases is focussed around the capabilities of the available demonstrator sites and the features and applications the project partners envision realizing. An overall high-level use case of a Smart City Information Centre and the three use cases relating to future demonstrator sites are detailed in this report. The described uses cases and scenarios will be used as a reference in the evaluation of the requirements and the design of the platform architecture in T2.2 & T2.3 as well as the technical work packages. The real world demonstrator will realise and evaluate parts of the use cases as chosen in WP6 of the project.

Upload: nguyenkhue

Post on 02-Jan-2017

247 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: D2.1-Use Cases.pdf

FP7-SMARTCITIES-2013 Project number: 609062 http://www.smartie-project.eu/

SMARTIE

Deliverable D2.1

Use Cases

Editor: Manfred Kopielski (GWS)

Dissemination level: (Confidentiality)

PU

Suggested readers: Other reader groups

Version: 1.0

Total number of pages: 39

Keywords: Smart City, scenarios, smart city information centre, traffic, transport, energy

Abstract

This document describes the initial use cases for the SMARTIE project taken from different thematic areas

of a smart city environment. The areas include the energy, transportation and traffic management. The

description of the use cases is focussed around the capabilities of the available demonstrator sites and the

features and applications the project partners envision realizing. An overall high-level use case of a Smart

City Information Centre and the three use cases relating to future demonstrator sites are detailed in this

report. The described uses cases and scenarios will be used as a reference in the evaluation of the

requirements and the design of the platform architecture in T2.2 & T2.3 as well as the technical work

packages. The real world demonstrator will realise and evaluate parts of the use cases as chosen in WP6 of

the project.

Page 2: D2.1-Use Cases.pdf

SMARTIE Deliverable D2.1

Page 2 of (39) © SMARTIE consortium 2014

Disclaimer

This document contains material, which is the copyright of certain SMARTIE consortium parties, and may

not be reproduced or copied without permission.

The information contained in this document is the proprietary confidential information of the SMARTIE

consortium and may not be disclosed except in accordance with the consortium agreement.

The commercial use of any information contained in this document may require a license from the proprietor

of that information.

Neither the SMARTIE consortium as a whole, nor a certain party of the SMARTIE consortium warrant that

the information contained in this document is capable of use, or that use of the information is free from risk,

and accept no liability for loss or damage suffered by any person using this information.

The information, documentation and figures available in this deliverable are written by the SMARTIE

partners under EC co-financing (project number: 609062) and does not necessarily reflect the view of the

European Commission.

Impressum

[Full project title] Secure and sMArter ciTIes data management

[Short project title] SMARTIE

[Number and title of work-package] WP2 Platform model

[Document title] Use Cases [Editor: Name, company] Manfred Kopielski, GWS

[Work-package leader: Name, company] Jens-Matthias Bohli, NEC

Copyright notice

2014 Participants in project SMARTIE

Page 3: D2.1-Use Cases.pdf

Deliverable D2.1 SMARTIE

© SMARTIE consortium 2014 Page 3 of (39)

Executive Summary

This document describes the initial use cases for the SMARTIE project taken from different thematic areas

of a smart city environment. The areas include the energy, transportation and traffic management. The

description of the use cases is focussed around the capabilities of the available demonstrator sites and the

features and applications the project partners envision realizing.

The document starts with a high-level view of a Smart City Information Centre as a central platform for

accessing suitable data by different stakeholders. The Smart City Information Centre can serve as the basis

for all departments that need to keep an overview of what is going on in the city but also serve as the

interface for setting up data sharing between stakeholders. The thematic areas of such a scenario are varying

from monitoring energy and water consumption, actual traffic or transport conditions, environment

parameters like temperature to reacting to crime or emergency incidents. Thus, a Smart City Information

Centre is an ideal use case to describe the full capabilities of a platform as it is envisioned by SMARTIE.

The document describes threats for security and privacy of the different stakeholders in a smart city Internet

of Things (IoT) platform. These internal and external threats have to be taken into account when designing

the platform model and evaluating the technical and functional requirements for the platform and its

subsystems. It is foreseen that secure communication, secure authentication, secure access control, secure

storage, data integrity and traceability solutions will be part of such a platform.

Following this first section, the three main use cases of the project partners are described in detail.

The Smart Energy Management Use Case describes scenarios of monitoring and control of the

energy use in several levels of granularity. The main focus here is a greater building complex, like

the campus of a university. But the use case also fits in scenarios with smaller or larger scale. So it is

very interesting for stakeholders like energy providers or public facility management providers. The

goal is a higher efficiency of the energy infrastructure and a higher information level of monitoring

entities.

The Smart Transport Use Case specifies scenarios to improve public transport service level using the

example of a bus network. Fleet management devices installed in the public busses will generate

Floating Car Data (FCD) and deliver it to the smart city platform. This data can be aggregated and

computed to provide routing and travel time information to travellers. They can use their smart

phones to gather detailed traveling information and monitoring entities could get concrete real time

data on demand.

The Smart Traffic Management Use Case details a scenario integrating several traffic infrastructures

to improve traffic flow and safety, with special attention to emergency incidents. Traffic measuring

sensors, traffic light-emitting diode (LED) displays and even traffic lights will be integrated in the

smart city environment. This will provide detailed real time traffic data to local authorities and

police departments. It also enables traffic managing entities to generate a greater impact of its

procedures and city planners to get historic traffic data.

The described use cases and scenarios will be used as a reference in the evaluation of the requirements and

the design of the platform architecture in T2.2 & T2.3 as well as the technical work packages. The real world

demonstrator will realise and evaluate parts of the use cases as chosen in WP6 of the project.

Page 4: D2.1-Use Cases.pdf

SMARTIE Deliverable D2.1

Page 4 of (39) © SMARTIE consortium 2014

List of authors

Company Author

GWS Manfred Kopielski

UMU Antonio Skarmeta, Miguel Angel Zamora, Victoria Moreno

DVNET Boris Pokrić

NEC Martin Bauer, Jens-Matthias Bohli

PTIN Ricardo Azevedo

IHP Peter Langendörfer, Anna Sojka-Piotrowska

Page 5: D2.1-Use Cases.pdf

Deliverable D2.1 SMARTIE

© SMARTIE consortium 2014 Page 5 of (39)

Table of Contents

Executive Summary ........................................................................................................................................... 3 List of authors .................................................................................................................................................... 4 Table of Contents .............................................................................................................................................. 5 List of Tables ..................................................................................................................................................... 6 List of figures .................................................................................................................................................... 7 Abbreviations .................................................................................................................................................... 8 1 Introduction ................................................................................................................................................ 9 2 Vision of a Smart City Information Centre .............................................................................................. 10

2.1 Overview Smart City Information Centre ......................................................................................... 10 2.2 Visualization ..................................................................................................................................... 11 2.3 Thematic Areas ................................................................................................................................. 11 2.4 Security & privacy threats ................................................................................................................. 13

2.4.1 External threats .......................................................................................................................... 13 2.4.2 Internal threats ........................................................................................................................... 13 2.4.3 Threat Handling ......................................................................................................................... 14

3 Demonstrator related Use Cases .............................................................................................................. 15 3.1 Smart Energy Management ............................................................................................................... 15

3.1.1 Use Case Description ................................................................................................................. 15 3.1.2 Use Case Scenarios .................................................................................................................... 16

3.2 Public Transport Scenario ................................................................................................................. 22 3.2.1 Use Case Description ................................................................................................................. 22 3.2.2 Use Case Scenario ..................................................................................................................... 24

3.3 Traffic Management Scenario ........................................................................................................... 30 3.3.1 Use Case Description ................................................................................................................. 30 3.3.2 Use Case Scenarios .................................................................................................................... 33

4 Conclusion ................................................................................................................................................ 38 References ....................................................................................................................................................... 39

Page 6: D2.1-Use Cases.pdf

SMARTIE Deliverable D2.1

Page 6 of (39) © SMARTIE consortium 2014

List of Tables

Table 1 List of Facilities .................................................................................................................................. 19

Page 7: D2.1-Use Cases.pdf

Deliverable D2.1 SMARTIE

© SMARTIE consortium 2014 Page 7 of (39)

List of figures

Figure 1 SCIC Overview ................................................................................................................................. 10 Figure 2 Overview of the Open Data architecture ........................................................................................... 17 Figure 3 View of a control cabinet with the controllers IPex16 ...................................................................... 18 Figure 4 Snapshot of Open Data SCADA web in one of the controlled buildings ......................................... 18 Figure 5 Sequence diagram of SMARTIE Platform for energy efficient buildings ........................................ 21 Figure 6: public transport IoT platform functional diagram ............................................................................ 25 Figure 7 Illustration of a possible response to traveller request: (a) bus stop with AR marker; (b) bus arrival

time information on traveller’s smartphone following the AR marker scanning; (c) detailed information

on available routes as requested by traveller ............................................................................................ 26 Figure 8 Sequence diagram of service usage ................................................................................................... 28 Figure 9 Sequence diagram of service usage ................................................................................................... 29 Figure 10 Traffic Safe display unit .................................................................................................................. 30 Figure 11 integrated systems ........................................................................................................................... 32 Figure 12 sequence diagram of emergency scenario ....................................................................................... 34 Figure 13 Sequence diagram of congestion scenario ...................................................................................... 36

Page 8: D2.1-Use Cases.pdf

SMARTIE Deliverable D2.1

Page 8 of (39) © SMARTIE consortium 2014

Abbreviations

3G Third generation of mobile telecommunications technology

AR Augmented Reality

CoAP Constrained Application Protocol

CPU Central Processing Unit

FCD Floating Car Data

GPRS General Packet Radio Service

GPS Global Positioning System

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

HVAC Heating, Ventilation, Air Conditioning

IoT Internet of Things

JGSP Public City Transport Company of Novi Sad

LED Light-Emitting Diode

MCU Microprocessor Control Unit

SCADA Supervisory Control and Data Acquisition

QR Code Quick Response Code

UDP User Datagram Protocol

Page 9: D2.1-Use Cases.pdf

Deliverable D2.1 SMARTIE

© SMARTIE consortium 2014 Page 9 of (39)

1 Introduction

This deliverable describes the vision of a smart city and a set of real use cases within the context of several

smart city areas such as transportation, energy or public safety. These use cases will be the basis for

extracting the functional and security requirements, as well as for the final demonstrator developed in WP6.

The main objective of the use case description is to define possible real world applications for the project

results. The document describes the scenario of a smart city environment and the benefits that it offers. After

the vision of the high-level overall scenario that is described in Section 2, three concrete use cases in the area

of energy management, public transport and traffic management are defined in Section 3, 4 and 5.

The description of the use cases is one of the first main tasks of the project. It is firstly the basis of the

formulation of functional and technical requirements and secondly the development of the platform

architecture. Large parts of the use case descriptions will contribute to the specification of the test scenarios

and some major benefits of the use cases will be demonstrated in the future project progress.

The use case description document is aimed at the following audiences and respectively at the fulfilment of

the following objectives:

European Commission: to inform about the identified use cases and the planned development

Consortium partners: to inform them about the use cases and as initial point for T2.2& T2.3

Others: any external individual or entity interested in the public results achieved within the scope of

the SMARTIE project.

Page 10: D2.1-Use Cases.pdf

SMARTIE Deliverable D2.1

Page 10 of (39) © SMARTIE consortium 2014

2 Vision of a Smart City Information Centre

SMARTIE is targeting a secure Internet of Things (IoT) platform for smart cities. Its core focus is on

developing a number of technologies to fulfil the needs of the different users of such a platform with respect

to security, privacy and trust. For better understanding the specific requirements, as well as demonstrating

the results, the SMARTIE project has three concrete use cases in the areas of traffic, energy and transport.

These use cases are representative for the use of IoT technology, but have to be small in scale since an IoT

infrastructure is not yet widely available. Nevertheless our target goes beyond small silo use cases towards

an integrated smart city IoT infrastructure, where sensors and actuators originally deployed for one purpose

can be re-used for other purposes, enabling a whole smart city ecosystem. To show how an integrative use

case could look like and to derive additional requirements, we have selected a smart city information centre

use case. As the practical scale of this use case goes beyond what we can develop in this project, we will

describe it on a higher abstraction level and with less detail than the concrete use cases.

In the following, we describe the vision of a smart city information centre and show how information from

the concrete SMARTIE use cases can be processed and used to enable functionality that goes beyond the

original purpose.

2.1 Overview Smart City Information Centre

The idea of a smart city information centre is to gather all the information about a city and provide access to

it on a suitable abstraction level. The purpose is to give the responsible people a quick overview of what is

going on in the city and whether there are issues that require attention, possibly indicating a level of urgency.

To achieve this, suitable visualizations of the information is needed with the possibility to increase the

granularity, i.e. to zoom into a problem area.

Figure 1 SCIC Overview

The thematic dimensions that could be included are traffic, public transport, and energy production &

consumption as covered by the SMARTIE use cases, but also water management, irrigation of parks,

pollution, noise, temperature, crowd movement, public safety, communication infrastructure, parking

Page 11: D2.1-Use Cases.pdf

Deliverable D2.1 SMARTIE

© SMARTIE consortium 2014 Page 11 of (39)

situation and possibly others. To understand the situation and how it develops, single data points showing the

current situation are not sufficient, but the data needs to cover the spatial and temporal dimensions.

The smart city information centre can serve as the basis for all departments that need to keep an overview of

what is going on in the city. As the result of privatization, this may also include companies that have taken

over certain public services. The overall information provided goes beyond what would be available through

the information sources of a single city department or company, e.g. for the traffic case additional

information related to the cause of the problem like movement of crowds, flooding or a fire, could be highly

relevant. Finally, the city information centre can be used as a basis for coordinating activities of different

agencies, e.g. the fire brigade and traffic management in the case of fires or floods. Having different thematic

aspects accessible in the same place allows the automatic correlation of different information and creating

alerts when a critical situation is detected. This could be especially relevant for an area like public safety.

Visualization

At the highest overview level, the different thematic aspects could be visualized using icons with colours,

e.g. traffic light colours with green for normal situation, yellow for moderate deviations and red for critical

situations. This requires processing of the original information, first aggregating to the desired level of

granularity, classifying the results according to the levels and taking the maximum / minimum for

visualization on the coloured icon.

Choosing a thematic aspect, the current situation could be visualized in the spatial dimension, i.e. on a map,

identifying problem areas. For this purpose, data points on the relevant granularity level have to be

visualized in the spatial dimension.

In certain cases, it is important to show the development over time. This means that historic information for

individual values or spatial areas have to be visualized. In certain cases, projections for the future would be

desirable. This requires simulation models that can make predictions, e.g. based on previously encountered

developments.

Once a problem has been detected in a certain area, it would also be desirable to get more detailed

information about this, i.e. to zoom into this area. For this purpose, more data or more accurate data may be

required. This data may not be made generally available by the information provider, but could potentially be

made available to authorized people given that an emergency situation has been reliably detected. Also, new

information sources, which were previously on standby, may be activated to get a more detailed picture.

2.2 Thematic Areas

The energy production and consumption could be visualized on a per block or even per city district area. The

original information on a per building, per apartment or even per room basis that is available in the Smart

Energy Management use case is too fine-granular and has related privacy issues. Therefore, only the

aggregated information could be made available to the Smart City Information Centre. This requires some

processing within the trusted part of the Energy Management subsystem and a suitable access control making

sure that only the aggregated information is made available to the Smart City Information Centre. It could be

investigated whether a context-dependent access policy, that allows authorized access to detailed information

once an emergency situation has been identified in a reliable manner, should be implemented. Apart from the

primary energy stakeholders like energy providers and energy consumers, this information could be relevant

for supervisors, policy makers, planners, as well as citizens in general. Especially in the case when the

energy consumption has to be restricted as it was the case in Japan after the Fukushima nuclear disaster such

information can provide the necessary transparency.

The traffic situation in the city could be first visualized on a district level, requiring the processing of the

more detailed information. If a higher granularity is required, the information could be provided on a per

street section per direction basis. However, this should be done in an anonymized fashion. Depending on

how the information is collected, the individual vehicle may be visible within the traffic subsystem, which

should not be provided to the Smart City Information Centre. So again, processing within a trusted

Page 12: D2.1-Use Cases.pdf

SMARTIE Deliverable D2.1

Page 12 of (39) © SMARTIE consortium 2014

subsystem and access control is required. The traffic information is relevant for a number of stakeholders

from the traffic department, to transport providers, citizens and the police.

The public transport situation may give indications whether there are any unusual movements of people,

possibly due to planned or spontaneous events. Depending on the situation, additional transport capacities

need to be made available, or people should be advised as early as possible to take other, less frequented

routes. For this purpose neither the specific transport vehicle, nor information about individual passengers,

which may be available at the data collection point, are needed and thus also should not be made available to

the Smart City Information Centre, which requires processing at a trusted place within the public transport

subsystem. The stakeholders are generally the same as for the general traffic information with a stronger

focus on the users of the public transport system.

Unusual water consumption in the city may indicate problems, e.g. a burst pipe. This could also require

different agencies to become active, e.g. the fire brigade for initially fixing the problem and pumping water

out of flooded basements etc. Traffic may have to be redirected, and as a result public transport routes

changed. The current situation in these areas may also give important information on the location and scale

of the problem and what should be done first. Apart from the described big problems, it may be possible to

find problems before they occur. A small leakage may lead to a measurable increase in water consumption.

However, an increase in water consumption may also be due to a changed weather pattern, e.g. a heat wave.

A correlation with measured temperature and other weather information, e.g. the absence of precipitation,

may be useful in determining which case can be expected and thus what needs to be done. The primary

stakeholder is again the water management, but in case of problems like a burst pipe, the information is

relevant for the emergency services. In the case that water consumption needs to be restricted, e.g. due to a

draught, it may also provide the necessary transparency to citizens and authorities.

Unusual temperature values in parts of the city may indicate a problem, e.g. a fire. If overall temperature

values are especially high or especially low, actions may have to be taken and citizens may have to be

warned, especially those that have special needs, i.e. depending on the reason for the unusual temperatures,

the stakeholders are social services or emergency services and in all cases the citizens.

If pollution values in certain areas are high, this may point to a specific problem, e.g. a problem in a factory,

which requires immediate attention. Also, as mentioned above, a fire may cause problems. If pollution is

high in certain parts of the city traffic restrictions may have to be enforced. The main stakeholders are

emergency services and citizens.

The monitoring of noise levels may also lead to the detection of unusual situations, e.g. the formation of

crowds in certain places. If this information can be co-related with other information, it may be possible to

determine whether people are going to watch a football game or concert, or if a demonstration or even a riot

is forming. Using such information, it can be determined where security personnel are currently most

needed. The main stakeholders are those responsible for public safety like the police and other security

services.

If security incidents and crimes are reported with precise temporal and spatial information, suitable measures

can be taken to improve the safety in the city, e.g. by sending more security personnel to the respective areas

and by warning the people. The main stakeholders are again those responsible for public safety like the

police and other security services, but also the citizens who play an important role for reporting the

information, but also take the situation into account with respect to their own behaviour.

As can be seen from the above, there is a variety of different aspects that can be monitored and acted upon in

a smart city. Some of these aspects could be handled in separate, non-integrated systems. However, it can be

seen that the strength of the Smart City Information System lies in the correlation of information from

different sources that leads to more precise information and even new insights that can help to improve the

functioning of a smart city and thus the quality of life of its citizens.

Page 13: D2.1-Use Cases.pdf

Deliverable D2.1 SMARTIE

© SMARTIE consortium 2014 Page 13 of (39)

2.3 Security & privacy threats

The vision of a smart city information centre, monitoring and controlling huge parts of the city infrastructure

introduces several new threats to security and privacy issues. The core principles of information security are

confidentiality, integrity and availability that need also to be protected for many aspects of a Smart City

Information System. The system must be able to protect its information, avoid unauthorized modifications in

the city’s infrastructure, and be always available for information retrieval and control. Note that availability

is in particular needed in difficult situations and under attack, when e.g. rescue operations for public safety

need to be coordinated.

Critical city infrastructure must be protected from malicious attacks by security mechanisms in the IoT

platform. Furthermore the platform must control the access to private information of platform users and

subsystems. In general, the attacks can target the IoT infrastructure at any point from devices in the field,

communication channels, or servers. The attack might try to sabotage or compromise subsystems to take

over control of certain aspects of the city. Another target is the information data in the IoT platform, which is

compromising the privacy of the stakeholders and citizens.

We take in the following a closer look at the threats differencing between external and internal threats.

2.3.1 External threats

As a smart city IoT platform grants access to critical infrastructure and confidential data, it is likely a target

of external attacks. The smart city information centre platform will have to be resistant against external

attackers. External attackers can attack devices or communication channels. In particular the following issues

need to be taken into account:

• Unauthorized external data access: External attackers may try to access private data from users,

components or subsystems of the IoT environment. For example the energy consumption of city

areas or even single houses is potentially interesting for unwanted commercial use cases. The

platform stores the information sent by the sensors, so there is a risk of an attacker tries to access

private data or corrupt it.

• Unauthorized device control: There may be several actors integrated in the smart city environment

that are controlled automatically or via remote control. This could be display units, traffic lights,

heating systems or even fire doors. Misapplication of these devices by external attackers must be

prevented by the platform under all circumstances.

• Hacking and Sabotage: There are several scenarios conceivable where city infrastructure is

sabotaged by external attackers. The smart city platform will have to fend denial of service or man-

in-the-middle attacks. The platform must offer suitable mechanisms for intrusion prevention and data

encryption to prohibit failure of subsystems provoked by unauthorised outsiders. Once parts of the

system are compromised by the attacker, the attacker use this compromised subsystem to attack the

full smart city infrastructure, now acting as an internal attacker.

2.3.2 Internal threats

Caused by the complexity and multiplicity of the components, actors and users of the smart city environment

there are several internal security issues which have to be considered. Internal adversaries are in particular

dangerous. They have detailed knowledge about the infrastructure, direct access to or control of systems and

devices in the city infrastructure or IoT platform. They also hold or have stolen several keys in the system.

Insider attackers are

Users or administrators of subsystems.

Hackers who have compromised already parts of the system.

Recent reports on malware and backdoors in various systems show that hackers can easily manage to

compromise at least parts of a system. In an IoT system, in particular the restricted nodes cannot be

physically protected and are often the weakest link.

Page 14: D2.1-Use Cases.pdf

SMARTIE Deliverable D2.1

Page 14 of (39) © SMARTIE consortium 2014

• Once part or subsystem is compromised, hackers can act as internal attackers to the rest of the

infrastructure. The defence in depth principle must be followed to avoid that the compromise of

subsystems poses a major threat to the full infrastructure. This shows that security-by-design is

important when building a complex infrastructure.

• Unauthorized internal data access: Internal adversaries might have the possibility to bypass certain

access control mechanisms and therefore can have access to the raw data. If the data itself is

protected by cryptographic means, the access to meaningful plaintext is still difficult for internal

adversaries.

• Violation of data and device integrity: The integration of several subsystems into one platform

threatens data integrity of components with unexpected side effects from other components.

Software errors or hardware failures should not influence data or communication of other

components.

2.3.3 Threat Handling

These threats raise security issues that must be taken in account:

• Authentication - in every communication between sensors, platform or actuators the actors must authenticate each other in order to prevent that an attacker impersonate one IoT entity.

• Secure communication, data confidentiality - the communication must be encrypted so an attacker is

not able of listen it. The data is accessed and processed only by authorized entities, thus the data to be sent or stored need to be encrypted.

• Access control, authorization - the platform need to implement access control mechanisms to allow stakeholders to share some of their information with other specific stakeholders.

• Secure storage - the sensitive or private data should be stored encrypted, this way if an attacker could

reach it, he wouldn’t be able of using it.

• Data integrity - the platform has to have mechanisms (like cryptography) to detect that some data has

been corrupted

• Traceability - do the stakeholders share corrupted information and then deny it, the platform has to

be able to trace who share which information.

• Privacy – the data is accessible only to trusted parties and only within the platform.

• Data availability - the data which is processed or stored needs to be available to the authorized users

on demand. The main threat here are Denial of Service attacks. This type of attack can make the

communication between devices impossible or simply disable the devices containing the data or being on the transmission path.

• Data freshness – it cannot be possible that an attacker will send the outdated messages.

Page 15: D2.1-Use Cases.pdf

Deliverable D2.1 SMARTIE

© SMARTIE consortium 2014 Page 15 of (39)

3 Demonstrator related Use Cases

3.1 Smart Energy Management

3.1.1 Use Case Description

Over six billion people are expected to live in cities and surrounding regions by 2050 [1]. Consequently, the

autonomic and smart operation of cities will be a critical requirement in the near future. Challenges related to

the ability of city infrastructures to cover every citizen's needs in terms of water supply, transportation,

healthcare, education, safety, and, most importantly, energy usage must be addressed to save and improve

the economic, social and environmental well-being of citizens.

Since most of the human lifetime is spent indoors, buildings, which make up a city subsystem, require

special attention. Indeed, buildings are the cornerstone in terms of power consumption and CO2 emissions

on a global scale. In Europe, for instance, the area of energy management systems in buildings has only just

started but is rapidly moving towards a technology-driven status with rising productivity. This is mainly due

to the progress in the need to reduce energy and greenhouse gas (GHG) emissions in line with the EU 2020

and 2050 objectives.

The goal of this use case is to provide a reference system able to manage intelligently the energy use of the

most relevant contributor to the energy use at city level, i.e. buildings. In this sense, it is possible to identify

different ecosystems compounding a city, for example residential neighbourhoods, schools, hospitals,

campuses, etc. All these ecosystems can be seen as sets of buildings where people carry out different tasks

every day. Therefore, considering buildings as the common cornerstone of all these city systems, we propose

to deal with energy efficiency in buildings as main contributor to achieve energy efficient and sustainable

cities.

An energy efficient building is one that minimizes conventional energy consumption (i.e. non-renewable

energy) with the goal of saving energy and carrying out a rational use of it. Real-time behaviour of systems

jointly acting as a sustainable ecosystem is inconceivable without significant degrees of built-in automated

intelligence at different levels and in various components of the overall network involved in such

ecosystems.

Achieving energy efficiency in buildings requires the interaction between a number of actors and entities

providing energy monitoring and consumption feedback, using automation systems, sensors and actuators,

and carrying out economic strategies to save energy. In order to cover such requirements at city level, it is

necessary to provide a common platform which lets users be informed about energy usage aspects as well as

interact with the system to define specific strategies for saving energy or control their own devices integrated

in the platform.

Due to the platform including devices and data whose owners can be external agents to the platform owner,

security requirements must be satisfied to ensure user privacy, trusted data sources, confidentiality or secured

communication, among others.

For all these reasons framed in the SMARTIE platform, we propose to cover the use case of smart energy

management of buildings where it is envisioned to enable end-to-end security and trust in information

delivery for decision-making purposes addressing energy efficiency issues and following data owner’s

privacy requirements.

The pilot will be set in the Region of Murcia, where different city facilities will be monitored and managed

by the SMARTIE platform to deal with energy efficiency at city level. Murcia already has several target

facilities in which energy consumption aspects have been identified as relevant due to their contribution to

the energy consumption at city level. Among others, public facilities such as schools, hospitals and public

buildings are being monitored in terms of their energy usage behaviour. Therefore, energy consumption

levels associated to different city subsystems can be provided to become citizen and government aware about

this aspect. Besides, strategies to save energy in such facilities can be defined as well as future plans for

more energy efficient performances of cities.

Page 16: D2.1-Use Cases.pdf

SMARTIE Deliverable D2.1

Page 16 of (39) © SMARTIE consortium 2014

On the other hand, the University of Murcia (UMU), which is one of the biggest Universities of Spain,

already has a large amount of facilities monitored and controlled. This university has three main campuses

and several facilities deployed throughout different cities in the Region of Murcia. During the last three

years, the Maintenance Department of this university, in collaboration with the Department of Information

and Communication Engineering, has gone for the technological innovation in the field of monitoring and

control of buildings’ infrastructures distributed along the university area.

Considering these demonstrators of the use case of smart energy management framed under the perspective

of the SMARTIE platform, in the next section we describe different scenarios where test and validation of

the SMARTIE platform can be carried out.

3.1.2 Use Case Scenarios

The planned SMARTIE public energy management system for smart buildings following the instantiation of

the generic use case presented above, including the functional relation among system components, is

presented in this section.

We can distinguish different actors involved in the overall system under analysis. These actors are:

• Energy producer: a network of photovoltaic generators working as an alternative energy source

(grid) that are owned by private entities but provide energy to the target consumer based on request.

This include sensor nodes across all photovoltaic generators in order to get information

• Energy consumer: different buildings with sensors deployed in the environment (light, temperature,

energy consumption, presence, etc.) and using these data to monitor and control certain subsystems

(Heating, Ventilation, Air Conditioning (HVAC), lighting, security, turn on/off of electric

appliances, etc.). These and more extended services can be managed intelligently taking into account

environmental parameters and patterns of behaviour of users, avoiding much wastage of energy that

often are used in overage.

• Energy monitoring entity: it could be the own entity of the city facility considered, or a third party,

for example a subcontracted company that provides a platform that ensures the integration and

management of different kinds of data sources, such as intelligent sensors, alarm control units,

mobile devices, etc. and finally, an intelligent management system must provide users with proper

adaptability, both environment and behaviour, to cope with most important energy efficiency

requirements, and provide support for real-time decisions in order to improve energy efficiency

while retaining different user-acceptable comfort levels of the services provided.

• Energy supervisor entity: it is in charge of evaluating the economic strategies and collecting the

monitoring data provided by the different entities and then, following the energy balance status,

gives advice, provides good practice and suggestion to the different partners.

• End user: the scenario will include the user involved by means of her Smartphone for instance, in

order to interact with the management system. For example, in the case of being detected in the

nearby of some presence sensors points and based on this lets the system take into account her

presence to act over the lights, streetlight, HVAC, etc.

The smart energy management use case will cover three main scenarios, these are:

• Smart Campus: considering the Campus of Espinardo of the University of Murcia.

• Smart Building: considering the Pleiares building fully monitored and automated since their early

stages of design.

• Smart Public Facilities: considering the monitoring data available and provided by the project

partner INFO about the energy consumption of the most relevant facilities distributed throughout the

Region of Murcia.

Page 17: D2.1-Use Cases.pdf

Deliverable D2.1 SMARTIE

© SMARTIE consortium 2014 Page 17 of (39)

All these scenarios will be based on the building management platform called Open Data. This platform is

derived from some improvements and expansions made over the initial platform presented as Domosec,

which was developed by the Dept. of Information and Communication Engineering of the University of

Murcia. Domosec was fully described in [2].

Open Data is the platform of the University of Murcia in charge of monitoring and controlling the different

buildings’ infrastructures connected to the system. The platform is based on multi-user Supervisory Control

and Data Acquisition (SCADA) web technology that centralizes all the sensor information and carries out the

intelligent programmed actions.

The connection among the different buildings and the platform is done through IP-based connections.

Depending on the technology of the manufacturer, these connections can be linked directly to the SCADA or

by means of an IP expansion controller (IPex16). The IPex16 are IP- based controllers able to connect all

kinds of sensors and control units to Internet (Figure 1).

IPex16 supports the most important smart building technologies and provides an easy way to connect sensors

and actuators to the platform. This controller can be used to connect non-IP sensors or actuators to the

network or also can be used as a gateway between different technologies (wired and wireless).

Figure 2 Overview of the Open Data architecture

The installation of the IPex16 control units in the different electrical cabinets of a building enables to manage

easily the infrastructure of this facility (Figure 2).

Page 18: D2.1-Use Cases.pdf

SMARTIE Deliverable D2.1

Page 18 of (39) © SMARTIE consortium 2014

Figure 3 View of a control cabinet with the controllers IPex16

The SCADA web provides a database where are stored all monitored and available data about the different

automated buildings.

The information is collected in the database, and this can be showed through an easy-to-use frontend client

application with 3d plans of the different rooms and floors of each building (Figure 3). The platform also

provides access to other platform or software through its interfaces.

Figure 4 Snapshot of Open Data SCADA web in one of the controlled buildings

The University of Murcia has been involved in energy efficiency goals for several years. The initial

motivation was to connect each appliance to a common platform which was independent on a private

manufacturer, with the main goal of the tele-maintenance of the infrastructures of seven buildings distributed

in one of the three campuses of the university. Nowadays, the number of buildings monitored and the

automated services provided by these has increased quickly.

Specifically, the number of facilities connected to this platform is about 30 (see Table 1).

The services offered in each building are different depending on their facilities. Although most of the

buildings have connection with fire control units and its fire detection sensors, as well as with the security

control units provided by the security policy of the University, in some buildings are not deployed yet all

Page 19: D2.1-Use Cases.pdf

Deliverable D2.1 SMARTIE

© SMARTIE consortium 2014 Page 19 of (39)

services offered by the Open Data Platform. Therefore, we propose in this document a mapping of the

sensors and systems that would be required to deploy for its inclusion to the SMARTIE Platform.

Table 1 List of Facilities

Currently, the UMU facilities have a set of controllers installed in different buildings to connect sensors,

actuators and non-IP Control Unit to the control network of the Open Data platform.

So far, we have made a brief description about the platform developed by the University of Murcia for

providing different services in buildings, such as tele-monitoring, alarms management, access control or

efficiency energy usage. Now, the proposal is to use the information provided by all sensors and systems

deployed among different monitoring buildings in the Region of Murcia to feed the final SMARTIE

platform, with the Internet of Thing philosophy and centred on energy efficiency in buildings.

Espinardo Campus

1 Computer Science Faculty

2 Psychology Faculty

3 Social Sciences Faculty

4 Experimental Animals Facilities

5 Sports Facilities

6 Business Administration and Management Faculty

7 Childhood support Center

8 Communication Studies Faculty

9 Veterinary science Faculty

10 Clinic Veterinary Hospital

11 Chemistry Faculty

12 Mathematics Sciences Faculty

13 House of students building

14 Rector Soler Building

15 Main Library building

16 Gines de los Rios Lecture room Facilities

17 Education Faculty

18 Luis Vives Building

19 Fine Arts Faculty

20 Pleiares Building

Merced Campus

21 Lawyer Lecture room Facilities

22 Merced Lecture room Facilities

Health Campus

23 Laib building

Murcia City

24 Rector Lostau Building

25 Seevedra Fajardo Building

26 Convalecencia Building ( Chancellor Building)

27 Mayor Azarbe Student Residence

San Javier City

28 Sport Sciences Faculty

Fuente Alamo Technological Park

29 CTT Fuente Alamo

Lorca City

30 Business Administration and Management

Page 20: D2.1-Use Cases.pdf

SMARTIE Deliverable D2.1

Page 20 of (39) © SMARTIE consortium 2014

For this goal, we propose to use the networks of sensors, actuators and systems already deployed at the

different monitoring buildings, connecting the IP-sensors and IPex16 controllers directly to the proposed

SMARTIE platform. In particular:

Energy production monitoring:

• Inverters connected to the solar panels provide energy power (Watts) and energy production (kWh) of

the solar energy in real time.

• Environmental sensor data are available (temperature and solar radiation) to check the system

performance.

Energy consumption monitoring:

• Temperature sensors in each room where there is a split HVAC.

• HVAC control per room (on/off and different alarms)

• Readings of energy consumption of the whole building through a connection with the power meter

device.

• Control of the fire sensors distributed along the buildings.

• Lighting control in classrooms.

• Monitoring of outdoor environmental conditions.

Energy supervisor:

• Possible actions over the buildings(actuators deployment)

o HVAC interaction: on/off, fan velocity, comfort temperature, disable/enable local control.

o In classrooms: lighting on/off, multimedia devices on/off.

o Street lighting: lighting intensity regulation in some LED street lights.

• Energy supervisor

o Information integrated in a SCADA web based system

o Using the information provided by the SMARTIE Platform, we evaluate the energy balance

status.

Below it is showed a sequence diagram (see Figure 4) that provides an overview of the usage of the

SMARTIE platform covering the smart buildings context to achieve energy efficiency at city level.

Page 21: D2.1-Use Cases.pdf

Deliverable D2.1 SMARTIE

© SMARTIE consortium 2014 Page 21 of (39)

Figure 5 Sequence diagram of SMARTIE Platform for energy efficient buildings

Page 22: D2.1-Use Cases.pdf

SMARTIE Deliverable D2.1

Page 22 of (39) © SMARTIE consortium 2014

Based on the possible interactions an initial set of security /privacy issues to be considered are:

Access to the sensor data should be controlled based on access control and privacy rules hence only

certain services of the entity monitoring could read or act over them specially in the case when the

monitoring entity is a third party.

In general the data exchange will require mechanisms including data protection and integrity during

the transfer between the different parties.

Scalable and secure management protocol which ensures verification and authentication of new

sensors deployed and allows the extension of the trust domain to the new devices in the deployment

environment.

Take into account the impact of data sharing in case of data exchange with third parties

Data exchange between entities needs to follow data minimization principles and allow traceability.

User data information usage could be in some cases anonymous and in other cases it should include

some control over the distribution of it.

3.2 Public Transport Scenario

3.2.1 Use Case Description

The system proposed in this use case aims to improve the management of the public transportation network

in the city of Novi Sad starting from the Public City Bus Transport Network with the intention to extend it to

other transport means and networks and thus promote and encourage the greater use of sustainable transport

modes and to provide time and cost benefits to travellers.

The pilot to be set in Novi Sad, Serbia will be based on enabling smart transport options for users of a public

transport focusing initially on 2 routes within a city public bus transport network operated by a local

transport company JGSP.

Bus stops covering the 2 routes will be equipped with the Augmented Reality (AR) markers in the form of an

image (e.g. logo or Quick Response Code (QR code)). Furthermore, fleet management devices will be placed

on the appropriate busses in order to track their location in real-time.

Users (travellers) will be able using their smart phones, dedicated application and the AR marker at the bus

stop to find out the bus arrival time and also request the information on the best route to the specified

destination depending on the user selected criteria.

Possible user selectable criteria will include:

1. the quickest route to the destination

2. route with the least changes

3. route with the least walking

4. route via specified place/stop

The best route to the destination in terms of criteria set will be calculated based on the user (traveller)

position, the specified travel destination and the positions of the buses on two routes obtained through the

fleet management devices.

The information will include the bus arrival time, estimated delay and the total estimated time to destination

based on a current traffic. The list of other possible options to the selected destination will also be provided

with the same information.

The initial application covering only the bus transport options will subsequently be extended to include

bikes, taxis and car parks providing the best ‘combined’ transport option (a multi-modal transportation).

Page 23: D2.1-Use Cases.pdf

Deliverable D2.1 SMARTIE

© SMARTIE consortium 2014 Page 23 of (39)

The system is targeted to the travellers using the public transportation network in Novi Sad, Serbia and the

direct benefits are the following:

• Efficient and cheap method for the public transport operators to convey important information to the

travellers without using expensive infrastructure such as LED displays at the bus stops.

• Efficient and attractive method available to travellers to better plan their trip in order to optimise time

and cost.

• Promotes and helps tourism in the city indicating tourist landmarks and integrating them within the

travel plans.

• Enabled access to real-time information on traffic status to all network operators including any delays

due to congestion or other disruptions.

• Optimisation of resources and number of vehicles by public city transport managers to respond

efficiently and appropriately to changing transport demands and provide a convenient and smoothly

running transport system.

• A better traffic flow achievable through potential optimisation of the traffic light system by city traffic

authorities who will have access to real time dynamic information on the current traffic status.

• A wider use of the satisfying and convenient service by public users (customers) which can plan their

routes.

Based on the information available, the system will be able to extrapolate a number of high-level services

that are used by different stakeholders or dedicated system components thus providing indirect benefits:

• Current traffic conditions along specified routes based on the information received from the fleet

management devices located on the public vehicles that are included in this platform. This is calculated

from the current travel time of public transport vehicles along certain routes versus expected. This

information can be used by the traffic authorities to potentially plan the traffic management actions in

order to avoid traffic jams or similar problems.

• Current demand of travellers for certain route (and for certain means of transport once the system is

extended to multimodal transportation). This is calculated from information received from the smart-

phone application where travellers specified their routing plan. This information can be used by the

public transport operator to manage the bus planning activities.

• Expected arrival times of public transport vehicles at certain location calculated from the current location

of vehicles and current traffic conditions. This information is useful to the public transport operator in

order to track the real bus arrival times against the planned.

The data generated by the fleet management devices are owned by the public transportation company and the

access to this data should be highly restricted to only authorised users. Furthermore, citizens will be

generating private data indicate the Global Positioning System (GPS) location as well as their travel plans.

This data stored within the cloud infrastructure should also be treated sensitive and access to this data should

not be made publicly available. Furthermore, it should be prevented that any unauthorised fleet management

devices are connected to the system. Therefore, it is necessary to establish access control policies for both

end users (or citizens) and for the IoT devices (i.e. fleet management devices) connecting to the back-end

cloud platform.

Any communication within the system must be made secure using the appropriate methods taking into the

account different layers within the system’s architectural stack. In particular, security mechanisms should be

able to address this issue whether operating on the powerful cloud back-end infrastructure, less powerful

mobile phone platforms or resource restricted IoT devices with limited memory, central processing unit

(CPU) processing power and low communication bandwidth.

The system infrastructure will address and prevent any potential threats at different levels of the system

utilizing the SMARTIE platform and solutions. This will be demonstrated through the following aspects:

Page 24: D2.1-Use Cases.pdf

SMARTIE Deliverable D2.1

Page 24 of (39) © SMARTIE consortium 2014

• Fleet management (GPS/ General Packet Radio Service (GPRS) ) devices mounted on the busses utilise

secure data transfer between the device and back-end infrastructure. Information related to location of

public vehicles should be accessible to system users according to the access policy and privacy rules.

• Users’ routing information stored on the cloud utilises security and privacy on the server side and secure

storage within the database.

• Preventing and disabling other users that wish to eavesdrop on other’s travel plans which rely on the data

privacy aspects implemented within the SMARTIE platform.

• Lightweight encryption primitives on devices and encryption level-dependant strength which

demonstrates dynamic adaptation of security method available within the SMARTIE platform.

• Power consumption of IoT device is not increased and thus demonstrates low-complexity security

algorithm executing on device (important when battery operated).

• Web portals secured by appropriate privacy rules are implemented to support the system by providing

access to real time information on transport requirements and traffic status which can be used by:

o JGSP to monitor the system and user’s requirements and provide efficient and convenient

transport service

o Police to identify potential transport/traffic problems causing big delays etc. and thus ensure a

safer transport system

3.2.2 Use Case Scenario

The planned SMARTIE public city transport system infrastructure following the instantiation of the generic

use case presented above, including the functional relation among system components is presented in Figure

6. The system components include:

Users (travellers) of the public bus transport interacting with the system using their smart phones, a

dedicated mobile application and associated AR markers available on specified bus stops.

Bus stop(s) used/covered by 2 specified bus operating lines with a 2D (image) bar code on each of

them

Mobile Network Operator providing a GPRS/ third Generation (3G) channel for data transfer from

the smartphones and fleet management devices to the back-end server

All the buses operating on 2 specified lines with a fleet management device, tracking the location in

real-time

Back-end cloud platform providing the core functionality of the system including communication,

routing calculation, AR content generation, web server

Web portals providing access to the system for the JGSP and other stakeholders for the report

generation purposes, definition of AR content, bus stops management (i.e. location)

The fleet management devices i.e. location sensors installed on busses are based on the GPS/GPRS

modems and associated microprocessor control unit (MCU). The location data collected are

transferred to the back-end server in the encrypted format and stored in the trusted and secured

storage.

The lightweight encryption is implemented on the fleet management devices effectively enabling

secure Constrained Application Protocol (CoAP)over Hypertext Transfer Protocol (HTTP) or User

Datagram Protocol (UDP). Communication between the smartphones and back-end server is

performed using standard Hypertext Transfer Protocol Secure (HTTPS).

Back-end is securely connected to the JGSP infrastructure via associated web services using HTTPS.

Back-end also provides a number of web applications using appropriate privacy rules and

Page 25: D2.1-Use Cases.pdf

Deliverable D2.1 SMARTIE

© SMARTIE consortium 2014 Page 25 of (39)

mechanisms. Data transfer between clients and back-end is realised using secure means (e.g.

HTTPS).

Back-end secure data storage (using appropriate security algorithms) contains all the information

related to the scenario, including user accounts1, buses routing, buses current locations, AR content,

travellers routing2 etc.

Figure 6: public transport IoT platform functional diagram

An example of using the Smart City Transport Application in the city of Novi Sad is illustrated in Figure 7.

Once at the Bus Stop with the AR marker (Figure 7a), the traveller can scan the AR marker and instantly

obtain the information on bus arrival times for all available routes (Figure 7b). In addition to this, the

traveller can request a more detailed information regarding travelling to desired location and based on this

the travel plan component located on the cloud infrastructure calculates the best routing option for the

traveller taking into account the traveller location, expected arrival times and current traffic conditions. This

information is then forwarded to the associated smart phone application and presented to the traveller as

shown in Figure 7c.

In addition to specifying the desired route (and means of transport once the system is extended to enable

multi-mode transportation) and obtaining the requested information on bus arrival times etc., the smart phone

application is able as mentioned above, IF agreed by the traveller, to collect the real-time positioning

information as well as output of acceleration sensors and upload this to the backend cloud server also in the

encrypted format and store in the associated trusted and secure storage. In this way, access to the personal

data is restricted only to the parties defined by the access policy framework rules.

1 Only if agreed by user/traveler

2 Same as 1

Page 26: D2.1-Use Cases.pdf

SMARTIE Deliverable D2.1

Page 26 of (39) © SMARTIE consortium 2014

Figure 7 Illustration of a possible response to traveller request: (a) bus stop with AR marker; (b) bus

arrival time information on traveller’s smartphone following the AR marker scanning; (c) detailed

information on available routes as requested by traveller

The service will be available to three main users of the Smart Transport IoT Platform, namely:

1. City public bus transport network operated by JGSP (monitoring and publishing)

a. Monitoring real-time location of buses

b. Monitoring historical data of busses location

c. Monitoring desired traveller routes as specified by the end users through smart phone

application

d. Publishing bus timetables, bus arrival times, bus routes and bus stop locations

2. Travellers (data exchange using the associated smart phone application)

a. Utilizing the calculated routes by the travel plan component

b. Provide the desired routing of transport information

c. Provide location and activity data

3. City Authorities (monitoring and publishing)

a. Monitoring real-time location of public vehicles

b. Monitoring historical data of public vehicles location

c. Publishing tourist related information (e.g. landmarks)

Page 27: D2.1-Use Cases.pdf

Deliverable D2.1 SMARTIE

© SMARTIE consortium 2014 Page 27 of (39)

These will be achievable through deployment of the following sensors:

1. Location sensors (on busses and users’ smart phones)

2. Activity detection sensors based on accelerometers available on users’ smart phones

Following sequence diagrams shown in Figure 7 and Figure 8 provide overview of the usage of the available

services.

Page 28: D2.1-Use Cases.pdf

SMARTIE Deliverable D2.1

Page 28 of (39) © SMARTIE consortium 2014

Traveller

Bus fleet

management

device

Public transport

operator

(JGSP)

JGSP

infrastructure

City traffic

authority

City

administration

Define bus routes

Calculate bus arrival times

SMARTIE

platform

Define bus stop

locations

Define tourist landmarks

Upload bus locations

Authenticate and

store bus locations

Upload traveller locationsAuthenticate and

store traveller

locations

Authenticate the user

Authenticate the user

Request bus arrival times

Request bus location

data

Send bus arrival times

Request tourist landmark info

Correlate with bus stop locations

Send bus arrival times

Request route information

Store route

information

Calculate route

Send route information

Request bus arrival

history

Store bus arrival

times

Get arrival times

Send bus arrival

history

Figure 8 Sequence diagram of service usage

Page 29: D2.1-Use Cases.pdf

Deliverable D2.1 SMARTIE

© SMARTIE consortium 2014 Page 29 of (39)

Traveller

Bus fleet

management

device

Public transport

operator

(JGSP)

JGSP

infrastructure

City traffic

authority

City

administration

SMARTIE

platform

Request bus arrival

history

Get arrival times

Send bus arrival

history

Create report

Authenticate user

Authenticate the user

Request bus delays

Get arrival times

Create report

Send bus delay report

Authenticate user

Authenticate the user

Request landmark statistics

Get routing

information

Create report

Send landmanrk statistics

Figure 9 Sequence diagram of service usage

Page 30: D2.1-Use Cases.pdf

SMARTIE Deliverable D2.1

Page 30 of (39) © SMARTIE consortium 2014

3.3 Traffic Management Scenario

3.3.1 Use Case Description

One of the main future challenges for urban administrations will be the management of the constantly

increasing amount of urban traffic, especially in the metropolitan areas. In nearly every larger town in the

world, congestion situations affecting large areas of the inner city are a daily occurrence. This is not even

problematic because of the higher amount of noise and pollution caused by the traffic. It also causes higher

transport costs to the communities and decreases traffic safety considerably.

The aim of this use case is to use the SMARTIE platform and solutions to improve the traffic situation,

information level of the road user and traffic safety. Therefore the existing traffic infrastructure in a region

must be combined with the SMARTIE platform. This will enable the traffic management authorities to join

different traffic data sources and actuators to improve traffic flow and traffic safety in the relevant area.

Parts of this use case will flow into a pilot system in the city of Frankfurt (Oder), Germany. The pilot will

show the possibilities of the SMARTIE platform in Smart City Traffic Scenarios with a special attention to

emergency situations. Therefore the existing traffic infrastructure of Frankfurt (Oder) will be especially

considered in this use case description.

Nowadays there might exist different systems in a city area that monitor and/or influence the urban traffic.

The most obvious one is the traffic lights system, directly controlling the traffic flow via the different

switching cycles on the crossroads. Furthermore in some cities, there might be some traffic control systems,

consisting of traffic sensors and variable messages signs. It might give an actual overview of the traffic

situation to local authorities or even to the public via web based information services, which indirectly

influences the traffic flow in turn. Even systems for prioritizing public transport vehicles like busses might

exist in the city. Useful as all these systems might be, mostly they are completely independent from each

other. Thus, useful traffic data produced by one system might not be available to the second one. The goal is

to create an interconnection of different traffic relevant systems to improve their benefit.

Short revisiting the situation in Frankfurt (Oder), there are two systems relevant for this use case. When the

pilot will be implemented, there will be a traffic control system available in the city area, called Traffic Safe.

It consist of detectors and display units installed at the side of the street and of a central control unit.

The detection and display units are designed very modular and are supplied

with energy independent from the mains through photovoltaic. The data of the

detection modules is sent to the central unit via mobile data connection

(2G/3G), where it is processed and stored. Depending on special traffic

situations the display units are controlled by the central unit to show the

defined content.

The main focus of the system is to detect traffic situations, but there is a variety

of ingoing data conceivable, like:

• Traffic data (vehicle speed, traffic density, vehicle direction, …)

• Weather data (temperature, rainfall, fog, …)

• Sensor state data (height control, photo sensors, …)

• Bluetooth

• Video camera

• External data (e.g. Triggers via external APIs)

Figure 10 Traffic Safe

display unit

Page 31: D2.1-Use Cases.pdf

Deliverable D2.1 SMARTIE

© SMARTIE consortium 2014 Page 31 of (39)

The state of all components of a Traffic Safe installation can be accessed by users via client software or via

the browser (e.g. on a mobile phone).

The second system which has to be mentioned here is Traffic Green. Traffic Green is a system for

prioritising emergency vehicles at traffic lights, to increase safety and decrease travel times. It mainly

consists of a mobile vehicle unit and a stationary unit on the traffic light. The vehicle unit constantly detects

the position of the emergency vehicle via GPS and calculate possible travel routes. If the vehicle comes up to

a traffic light a registration telegram is send by the vehicle unit to the stationary unit on the traffic light via

radio transmission. This message is forwarded to the control unit of the traffic light. It causes the traffic light

to leave its normal switching circles. It enters a special mode where for all directions, except the direction the

emergency vehicle comes from are shown stop signals. This mode is held until the emergency vehicle passes

the crossing and a sign off telegram is sent by the vehicle unit, which triggers the traffic light to switch back

in normal mode again.

The Traffic Green system is in operation in Frankfurt (Oder) for over 10 years now. Today about 20

emergency vehicles (mostly fire trucks and ambulances) and over 30 traffic lights in the city are equipped

with the system.

Thus, the most important goal of this use case is to connect different independent systems, like the ones

mentioned here via the SMARTIE platform to avoid abnormal traffic situations or dissolve them quickest

possible if they have emerged.

This can be supported by:

• Traffic Detection: Real time detection and processing of relevant traffic information. Abnormal

situations or congestion can be detected immediately and counteractions can be initiated.

• Information Displays: The variable message signs offer a direct return channel to road. Thus, depending

on the situation, every kind of useful content can be shown to the road users. These can be information

like travel times or detour information, warnings like congestion warnings or even traffic signs like a

speed limit.

• Integrated system communication: The integration of nowadays separated systems to an Internet of

Things backend framework offers opportunities that these systems impact each other.

• Floating car data: Vehicles equipped with a GPS receiver and a direct or indirect data connection to the

SMARTIE network. These might be emergency or public transport vehicles or even pedestrians with a

smart phone.

• Monitoring: Local city authorities will be enabled to have a permanent overview of the traffic situation

and the possibility to intervent manually through Graphical User Interface.

Page 32: D2.1-Use Cases.pdf

SMARTIE Deliverable D2.1

Page 32 of (39) © SMARTIE consortium 2014

Figure 11 integrated systems

The outcome of such an integration supplies benefits to several targets. First of all it benefits the local

authorities with:

• More information about traffic situation in the area. With integrated systems more data sources are

accessible and produce more detailed traffic overview.

• More impact of traffic flow control measures by using different systems at the same time. For example it

is possible to combine rerouting information on an information display of the traffic control system with

a change of the switching cycles in an area, to dissolve congestion much quicker.

• Higher overall traffic safety. With more information about the actual traffic situation and a greater

impact of traffic control, local authorities have the ability to avoid unwished traffic situations. This might

be achieved by lowering the maximal allowed speed or by showing emergency messages to the road

users on demand.

• If the collected data is historic, local authorities might be able to improve their traffic planning and

management in the future.

On the other hand, there are benefits for the individual road user:

• More individual relevant information. The SMARTIE data might be pre-processed and made accessible

via web frontend. The important information like travel times can be shown on display units at the route.

• More individual safety. A well informed road user tends to drive more calm and safe. In addition there

are less emergency situations in the area and the better traffic flow decreases the risk of car accidents.

• Shorter travel times. The improved traffic management in the city area makes sure, that the road user is

directed the best route to his destination.

Page 33: D2.1-Use Cases.pdf

Deliverable D2.1 SMARTIE

© SMARTIE consortium 2014 Page 33 of (39)

It is obvious, that handling with traffic data and, what is more important, directly influencing traffic (e.g. via

traffic lights) leads to high demands for data security. So it is important to satisfy security requirements to

ensure authentication of users and devices, capability and confidentiality of the data. The system

infrastructure has to prevent potential threats for security and privacy at different tiers of the platform:

• Actual/historical location and routing information of emergency vehicles is confidential. It should only

be processed in a reasonable matter. The access to this information has to be restricted to authorized

users (e.g. emergency coordination centre) by suitable access policies.

• Status data and operational characteristics of single traffic lights (even more traffic light control system)

are highly confidential. Secure authorisation mechanisms will protect the communication and control

interfaces to the traffic light system from external attacks.

• Same applies to the data generated by traffic sensors or LED message signs. That data has to be only

accessible by the operator of the respective installation.

• All aforementioned data that is processed or stored by the SMARTIE platform has to be secured by

qualified server-side security and secure data storage.

• Encrypted device communication has to protect communication channels from sniffing and Man-in-the-

Middle attacks. In addition all high confidential data (credentials etc.) is stored encrypted in the backend.

The system architecture has to implement end-to-end security for every communication process.

3.3.2 Use Case Scenarios

Emergency Scenario:

In this scenario an every-day emergency situation appears anywhere in the city area, like a fire or an

ambulance transport. The emergency vehicle leaves the depot with blue light and siren. From now on the

Traffic Green vehicle unit detects the vehicle position via GPS and computes possible routes to the expected

destination. If it reaches a traffic light (respectively if it reaches a predefined distance to the traffic light), it

radio transmits the registration telegram to the Traffic Green stationary unit, installed on the traffic light.

This causes green lights on the route of the emergency vehicle - like described above.

Although speed and safety of the emergency vehicle are increased by this system, there is still an adverse

condition. The traveling cars in front of the emergency vehicle may not be aware of it, coming from the back

and even do not notice the siren. This leads to situations where the emergency vehicle has to wait for cars to

get out of the way. The idea in this scenario is, to bring the information about an approaching emergency

vehicle directly to the road users via variable message signs.

Indeed the Traffic Green mobile unit has no digital data connection on-board, which may be used for that.

The only data exchange interface is the radio transmitter used to communicate to the traffic lights.

Nonetheless the traffic lights control network operated by the local authorizes registers the emergency

vehicles through the special programs of the traffic lights. With the information, which traffic light was

toggled and what special program was used, the route of the emergency vehicle could be determined. As a

part of this Use Case, a secure application interface to the traffic lights control system has to be implemented

and connected to the IoT framework. It should offer the possibility to send route status telegrams to the

Traffic Safe system. These telegrams will be processed and control display units (LED signs) following a

predefined switching matrix. All signs on the determined route of the emergency vehicle will show a

warning message to road users, like “Attention! Emergency vehicle might near from behind.” This gives the

road users the possibility to be aware of the situation and react faster when the emergency vehicle is passing.

In this scenario the following components are included:

• Emergency vehicle (more precisely the on-board units) calculating the route in case of an emergency

drive and registering via radio transmission to upcoming traffic lights

• Traffic lights listening for incoming emergency vehicle transmission, controlling the switching cycles

and sending status information to traffic light operator

Page 34: D2.1-Use Cases.pdf

SMARTIE Deliverable D2.1

Page 34 of (39) © SMARTIE consortium 2014

• Traffic light operator monitoring and controlling the traffic lights. It also transmits information about

incoming emergency telegrams to SMARTIE platform

• SMARTIE platform providing an interface to traffic light operator, secure data storage and an interface

to traffic control system

• Traffic control central unit monitoring and controlling all connected LED variable message signs and

transceiving data to SMARTIE platform

• LED signs showing content requested by traffic control central unit

• Road users getting informed via variable message signs

Figure 12 sequence diagram of emergency scenario

trafficcontrol central

unittraffic light

traffic lightoperator

SMARTIEplatform

road useremergency

vehicleLED traffic

display

Start emergency drive

Transmit registration

Calculate route

Status update

Change switching cycles

Authenticate andstore status update

Calculate possible routes

Authenticate and transmittraffic light status update

Authenticatedisplay tocentral unit

requestLED content switch

Switch content

Confirm content switch

Display content

LED status update

Page 35: D2.1-Use Cases.pdf

Deliverable D2.1 SMARTIE

© SMARTIE consortium 2014 Page 35 of (39)

Congestion Scenario:

This scenario considers the reverse connection of the two systems. While in the emergency scenario the

Traffic Green system impacts on Traffic Safe via the connection of the traffic lights control network, in the

congestion scenario the Traffic Safe system should have influence to the traffic lights.

Considering a congestion situation with much traffic jams in the inner city area. This might be the case

especially on working days or right before holidays, like Christmas.

In this scenario radar sensors will be placed at useful places all over the city area. They measure the passing

vehicles and detect actual or upcoming traffic jam situations. Additionally variable message signs will be

installed in the city. If a congestion situation is emerging, the Traffic Safe system will control the LED signs

to show defined content. This could be traffic jam warnings or detour information (depending on the

situation and the place of the single sign). For example there might be a sign installed on the highway outside

of the city, which informs road users about the traffic situation and recommend road users to stay on the

highway to drive around the inner city area. The sensors might also use Bluetooth technology to detect travel

times. These travel times can be shown to road users, giving them an idea how long it will take for them to

pass routes with high traffic volumes.

On top, the interface to the traffic lights control system might be used to impact the traffic light switching

cycles. Depending on the actual traffic flow situation or determined travel times, the traffic lights extend the

time of the green phase in a useful travel direction. Through this, traffic jams might dissolve much faster.

In addition to the involved components of the Emergency Scenario the following component is included:

• Radar sensors constantly measuring traffic and transmitting the traffic data to traffic control central unit

Page 36: D2.1-Use Cases.pdf

SMARTIE Deliverable D2.1

Page 36 of (39) © SMARTIE consortium 2014

Figure 13 Sequence diagram of congestion scenario

Event Scenario

This scenario is a variant of the congestion scenario. Here the trigger event is not a traffic situation detected

automatically, but a human made event. This might be single time or recurring events, like fairs or big

demonstrations affecting the traffic situation in the whole city area.

So it’s much like the congestion scenario with a permanent traffic jam for the time of the event. All elements

of the congestion scenario will work here, too. In addition there might be the need to show different content

on the display units. This information will more focus on event information (for example hints for possible

parking lots). Even pedestrians might be informed by the display units, showing content with QR Codes

integrated leading to more detailed information.

Catastrophe Scenario

This scenario, as a mixture of all of the above, is the most complex one. Supposed that there is a catastrophe

scenery on the top of an important bridge, like a vehicle accident with many involved cars, which is leading

to bridge closing.

trafficcontrol central

unittraffic light

traffic lightoperator

SMARTIEplatform

road userRadar sensorLED traffic

display

Detect traffic jam situation

Status update

Change switching cycles

request changetraffic light program

Authenticate andrequest change of traffic light program

Authenticate display tocentral unit

requestLED content switch

Switch content

Confirm content switch

Authenticate andLED status update

Authenticate sensor to central unit

Display content

Authenticate sensor to central unit

Calculate traffic light programm

Switch content

Authenticate andstore status update

Authenticate and requesttraffic light program

Page 37: D2.1-Use Cases.pdf

Deliverable D2.1 SMARTIE

© SMARTIE consortium 2014 Page 37 of (39)

In this case many emergency vehicles will drive to the bridge to help injured people or firefighting. So the

road users will have to be informed about many emergency vehicles coming from the back, like in the

emergency scenario.

On the other hand such a situation will lead to a congestion situation in the inner city. This will be detected

by sensors and detour information has to be shown on LED signs.

As the very special case of an event, information content has to be shown on display units. Maybe this

content has to be real time generated to conform it to the actual situation (e.g. estimated time till reopening

the border bridge). For that the content of the LED signs has to be uploaded to it via mobile data connection.

The local authorities also might need video data from the catastrophe site to analyse the situation and

optimize their decisions. This can be delivered by video units installed on the bridge or important crossings

in the city area.

Page 38: D2.1-Use Cases.pdf

SMARTIE Deliverable D2.1

Page 38 of (39) © SMARTIE consortium 2014

4 Conclusion

This document describes the possible use cases for the SMARTIE project. It describes the vision of a Smart

City Information Centre, which grants access to all suitable information in a city area to the designated

beneficiaries. Three more concrete use cases are defined, that should be considered as embedded in the

complete Smart City Environment.

The Smart Energy Management Use Case describes scenarios of monitoring and control of the energy use in

single buildings, neighbourhoods or even greater city areas. The goal is a higher efficiency of the energy

infrastructure and a higher information level of monitoring entities.

The Smart Transport Use Case specifies scenarios to improve the management of the public transportation

network using the example of the bus network. Travellers will use their smart phones to gather detailed

travelling information and monitoring entities could get concrete real time data of demand.

The Smart Traffic Management Use Case details a scenario to integrate several traffic infrastructure like

traffic lights, traffic sensors and traffic displays to a complete system for traffic management purpose, to

improve traffic flow and traffic safety in the city area (especially in case of emergency).

The complexity of the described smart city scenario and the confidentiality of the data necessitate a high

attention to privacy and security in the whole systems. These issues must be countered by appropriate

mechanisms to secure authentication, secure communication access control, secure storage, data integrity and

traceability. This will be one of the main focuses of evaluation of the requirements and the design of the

platform architecture in T2.2 & T2.3.

Demonstrators have to be developed during the further procedure of the project in WP6 to evaluate the

developed project results. These test scenarios will be developed on the basis of the concrete use cases

described in this document. However the scenarios specified here are meant to give an overview of the

possibilities of a Smart City environment. While the real world tests will try to cover as much of the content

of the use cases as possible, they are not planned to cover every single point detailed in this document. The

concrete specification and design of the test beds will be done in T6.1.

Page 39: D2.1-Use Cases.pdf

Deliverable D2.1 SMARTIE

© SMARTIE consortium 2014 Page 39 of (39)

References

[1] Habitat, U. N. 2010. State of the world’s cities 2010/2011: Bridging the urban divide. Nairobi, Kenya:

UN Habitat.

[2] M. Zamora-Izquierdo, J. Santa et al., “Integral and networked home automation solution towards

indoor ambient intelligence,” Pervasive Computing, IEEE, no. 99, pp. 1–1, 2010