D2.1-Use Cases

Transcription

D2.1-Use Cases

FP7-SMARTCITIES-2013
Project number: 609062
http://www.smartie-project.eu/
SMARTIE
Deliverable D2.1
Use Cases
Editor:
Manfred Kopielski (GWS)
Dissemination level:
PU
(Confidentiality)
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.
SMARTIE
Deliverable D2.1
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 2 of (39)
© SMARTIE consortium 2014
Deliverable D2.1
SMARTIE
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 3 of (39)
SMARTIE
Deliverable D2.1
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 4 of (39)
Deliverable D2.1
SMARTIE
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
3.2.2
Use Case Scenario ..................................................................................................................... 24
3.3 Traffic Management Scenario ........................................................................................................... 30
3.3.1
3.3.2
Use Case Scenarios .................................................................................................................... 33
4 Conclusion................................................................................................................................................ 38
References ....................................................................................................................................................... 39
Page 5 of (39)
SMARTIE
Deliverable D2.1
List of Tables
Table 1 List of Facilities .................................................................................................................................. 19
Page 6 of (39)
Deliverable D2.1
SMARTIE
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 7 of (39)
SMARTIE
Deliverable D2.1
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 8 of (39)
Deliverable D2.1
1
SMARTIE
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 9 of (39)
SMARTIE
Deliverable D2.1
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 10 of (39)
Deliverable D2.1
SMARTIE
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 11 of (39)
SMARTIE
Deliverable D2.1
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 12 of (39)
Deliverable D2.1
SMARTIE
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 manin-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 13 of (39)
SMARTIE
Deliverable D2.1
•
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 14 of (39)
Deliverable D2.1
SMARTIE
3
Demonstrator related Use Cases
3.1
3.1.1
Smart Energy Management
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 15 of (39)
SMARTIE
Deliverable D2.1
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 16 of (39)
Deliverable D2.1
SMARTIE
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 17 of (39)
SMARTIE
Deliverable D2.1
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 18 of (39)
Deliverable D2.1
SMARTIE
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.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Espinardo Campus
Computer Science Faculty
Psychology Faculty
Social Sciences Faculty
Experimental Animals Facilities
Sports Facilities
Business Administration and Management Faculty
Childhood support Center
Communication Studies Faculty
Veterinary science Faculty
Clinic Veterinary Hospital
Chemistry Faculty
Mathematics Sciences Faculty
House of students building
Rector Soler Building
Main Library building
Gines de los Rios Lecture room Facilities
Education Faculty
Luis Vives Building
Fine Arts Faculty
Pleiares Building
Merced Campus
Lawyer Lecture room Facilities
Merced Lecture room Facilities
Health Campus
Laib building
Murcia City
Rector Lostau Building
Seevedra Fajardo Building
Convalecencia Building ( Chancellor Building)
Mayor Azarbe Student Residence
San Javier City
Sport Sciences Faculty
Fuente Alamo Technological Park
CTT Fuente Alamo
Lorca City
Business Administration and Management
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.
Page 19 of (39)
SMARTIE
Deliverable D2.1
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 20 of (39)
Deliverable D2.1
SMARTIE
Figure 5 Sequence diagram of SMARTIE Platform for energy efficient buildings
Page 21 of (39)
SMARTIE
Deliverable D2.1
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
3.2.1
Public Transport Scenario
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 22 of (39)
Deliverable D2.1
SMARTIE
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 smartphone 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 23 of (39)
SMARTIE
Deliverable D2.1
•
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 24 of (39)
Deliverable D2.1
SMARTIE
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
2
Only if agreed by user/traveler
Same as 1
Page 25 of (39)
SMARTIE
Deliverable D2.1
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 26 of (39)
Deliverable D2.1
SMARTIE
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 27 of (39)
SMARTIE
Traveller
Deliverable D2.1
Bus fleet
management
device
Public transport
operator
(JGSP)
JGSP
infrastructure
SMARTIE
platform
City traffic
authority
City
administration
Define bus routes
Define bus stop
locations
Define tourist landmarks
Upload bus locations
Authenticate and
store bus locations
Upload traveller locations
Authenticate and
store traveller
locations
Authenticate the user
Request bus arrival times
Request bus location
data
Calculate bus arrival times
Store bus arrival
times
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
Get arrival times
Send bus arrival
history
Figure 8 Sequence diagram of service usage
Page 28 of (39)
Deliverable D2.1
Traveller
SMARTIE
Bus fleet
management
device
Public transport
operator
(JGSP)
JGSP
infrastructure
SMARTIE
platform
City traffic
authority
City
administration
Request bus arrival
history
Get arrival times
Create report
Send bus arrival
history
Authenticate user
Request bus delays
Get arrival times
Create report
Send bus delay report
Authenticate user
Request landmark statistics
Get routing
information
Create report
Send landmanrk statistics
Figure 9 Sequence diagram of service usage
Page 29 of (39)
SMARTIE
Deliverable D2.1
3.3
3.3.1
Traffic Management Scenario
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 30 of (39)
Deliverable D2.1
SMARTIE
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 31 of (39)
SMARTIE
Deliverable D2.1
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 32 of (39)
Deliverable D2.1
SMARTIE
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-theMiddle 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 33 of (39)
SMARTIE
Deliverable D2.1
•
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
emergency
vehicle
traffic light
operator
traffic light
SMARTIE
platform
traffic
control central
unit
LED traffic
display
road user
Authenticatedisplay to
central unit
Start emergency drive
Calculate route
Transmit registration
Change switching cycles
Status update
Authenticate and
store status update
Authenticate and transmit
traffic light status update
Calculate possible routes
request
LED content switch
Switch content
Confirm content switch
Display content
LED status update
Figure 12 sequence diagram of emergency scenario
Page 34 of (39)
Deliverable D2.1
SMARTIE
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 35 of (39)
SMARTIE
Deliverable D2.1
traffic light
operator
traffic light
SMARTIE
platform
traffic
control central
unit
LED traffic
display
Radar sensor
road user
Authenticate display to
central unit
Authenticate sensor to central unit
Detect traffic jam situation
request
LED content switch
Switch content
Confirm content switch
Authenticate and
LED status update
Display content
Calculate traffic light programm
Authenticate and request
traffic light program
Authenticate and
request change of
request change
Change switching cycles
Status update
Authenticate and
store status update
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.
Page 36 of (39)
Deliverable D2.1
SMARTIE
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 37 of (39)
SMARTIE
Deliverable D2.1
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 38 of (39)
Deliverable D2.1
SMARTIE
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
Page 39 of (39)

D2.1-Use Cases

Transcription

Similar documents

KNIT SMART STEPHANIE PEARL-McPHEE

Web of Objects Project Results at a Glance

Help the Silly Bus kids get to school!

October 2014

our faculty hiring brochure

Datasheet Pelton - Global Hydro Energy

Look. Donʼt touch.

Pimp my Ride!!