BIG IoT – Bridging the Interoperability Gap of the Internet of Things
Deliverable 2.2.a: Use Case Definition
Version 1.3
Date: 29.06.2016
This project has received funding from the European Union’s Horizon 2020 research and
innovation programme under grant agreement No 688038.
DELIVERABLE 2.2.A USE CASE DEFINITION
Responsible Person and Affiliation
D 2.2.A
VMZ Berlin:
Claudia Baumgartner, Christian Seidel,
Franka Heuer
Due Date / Delivery Date
29.06.2016
State
Final Draft
Reviewers
Achille Zappa (NUIG)
Werner Schladofsky (Atos)
Version
1.3
Confidentiality
Public
© 2016
1
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
List of Authors
Organisation
Authors
Main organisations’ contributions
VMZ
Claudia Baumgartner
Christian Seidel
Franka Heuer
CSI
Paolo Cravero
Nives Alciato
AAU
Lars Mikkelsen
WAG
Annelore Burggraf
UPC
Rosa Ma Martin
Lidia Montero
Bosch
Stefan Schmid
Siemens
Corina Kim Schindhelm
Jelena Mitic
Vodafone
Stefano Marzorati
Document structure
Generic parts (chap. 1, 2, 7, 8)
Chap. 4.1 (NG Pilot Description, Use cases
and services)
Chap. 5.1, 5.7, 5.8, 6.1, 6.4, 6.6
Contribution to Annex 2, 3
Compilation of Annex
Chap. 4.2 (Piedmont Pilot Description,
Use cases, services)
Chap. 5.4, 5.5, 6.2
Contribution to Annex 2, 3
Input to Chap. 4.1,
Chap. 5.3
Input to Chap. 7
Contribution to Annex 2, 3
Input to Chap. 4.1
Contribution to Annex 2
Chap. 4.3 (Barcelona Pilot description,
Use cases, services)
Chap. 5.2, 5.6, 5.9, 6.3, 6.5
Input to Chap. 7
Contribution to Annex 2, 3
Chap. 2.1, 3
Contribution to Annex 1
Chap. 9
Input to Chap. 3
Contribution to Annex 1
Input to Chap. 5, 7
Contribution to Annex 2, 3
© 2016
2
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
Table of Contents
ABBREVIATIONS ...................................................................................................... 5
DEFINITIONS AND VOCABULARY .......................................................................... 6
1
INTRODUCTION .......................................................................................... 7
1.1
SCOPE OF THIS DOCUMENT............................................................................. 7
1.2
EXECUTIVE SUMMARY .................................................................................... 8
2
METHODOLOGY ......................................................................................... 9
2.1
METHODOLOGY FOR BIG IOT ECOSYSTEM USE CASE DEFINITION ..................... 9
2.2
METHODOLOGY FOR PILOT USE CASES DEFINITION ........................................ 10
2.3
STRUCTURE OF THE DOCUMENT .................................................................... 11
3
BIG IOT ECOSYSTEM USE CASES ......................................................... 12
3.1
OBJECTIVE .................................................................................................. 12
3.2
ECOSYSTEM ACTORS ................................................................................... 14
3.3
ECOSYSTEM USE CASES .............................................................................. 15
4
PILOT DESCRIPTIONS ............................................................................. 22
4.1
NORTHERN GERMANY PILOT ......................................................................... 22
4.2
PIEDMONT PILOT .......................................................................................... 24
4.3
BARCELONA PILOT ...................................................................................... 26
5
PILOT USE CASE CLUSTERS AND USE CASE DESCRIPTIONS ......... 28
5.1
OVERVIEW USE CASE CLUSTER .................................................................... 28
5.2
SMART PARKING (SP) .................................................................................. 30
5.3
SMART TRAFFIC MANAGEMENT (STM) .......................................................... 32
5.4
PUBLIC TRANSPORT OPTIMIZATION (PTO)..................................................... 34
5.5
HEALTHY BIKE NAVIGATION (HBN) ............................................................... 36
© 2016
3
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
5.6
SMART BIKE SHARING (SBS) ....................................................................... 37
5.7
INCENTIVE-BASED GREEN ROUTE PLANNING (GRP) ...................................... 38
5.8
MULTIMODAL ROUTE OPTIMIZATION (MRO) ................................................... 40
5.9
SMART CHARGING (SC) ............................................................................... 42
5.10
DEVICE TO DEVICE COMMUNICATION (D2D) ................................................... 43
6
USE CASE SCENARIOS ........................................................................... 44
6.1
NORTHERN GERMANY PILOT ......................................................................... 44
6.2
PIEDMONT PILOT .......................................................................................... 50
6.3
BARCELONA PILOT ...................................................................................... 53
6.4
SMART PARKING IN NORTHERN GERMANY – PIEDMONT - BARCELONA............. 55
6.5
SMART TRAFFIC MANAGEMENT IN PIEDMONT AND BARCELONA....................... 55
7
SERVICES (OUTLOOK) ............................................................................ 58
8
INTEROPERABILITY IN USE CASES ...................................................... 61
8.1
PROJECT DEFINITION OF INTEROPERABILITY .................................................. 61
8.2
INTEROPERABILITY CHECK............................................................................ 64
9
CONCLUSION AND OUTLOOK................................................................ 66
FIGURES AND TABLES.......................................................................................... 67
D2.2.A ANNEX: USE CASE AND SERVICE DEFINITION
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS
4
PART 2: PILOT USE CASE DESCRIPTIONS
23
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS (OUTLOOK)
© 2016
112
4
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
Abbreviations
Abbreviation
BCN
BIG IoT
DOA
IoT
NG
PIE
Meaning
Barcelona (pilot)
Project title: Bridging the Interoperability Gap of the Internet of Things
Description of Action
Internet of Things
Northern Germany (pilot)
Piedmont (pilot)
© 2016
5
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
Definitions and Vocabulary
In this document several terms that are often used differently even in expert discussions. To
clarify the meaning of those terms in the context of this deliverable the following table provides a definition of terms.
Term
Use Case
Use Case Cluster
Use Case Story
Use Case Scenario
Offerings
Meaning in Document Context [Reference to Source]
“A use case describes a set of activities of a system from the viewpoint of its
actors. The activities lead to a noticeable result for the actors. A use case is
always initiated by an actor.” cf. [Oesterreich 2001 p. 199]
A Use Case Cluster is the "topic" for different Use Cases within different
pilot sites. [BIG IoT]
The Use Case Story is “a front-to-back flow through a use case”. cf. [Schaaf
2012: 2]
The use case scenarios show the individual use cases put into practice by
comprehensive user stories.
[BIG IoT]
Resources that are provided using the BIG IoT ecosystem
© 2016
6
DELIVERABLE 2.2.A USE CASE DEFINITION
1
D 2.2.A
Introduction
The objective of BIG IoT project is to establish an Internet of Things (IoT) ecosystem to
bridge the interoperability gap between IoT platforms. To enable this, an IoT ecosystem will
be provided that offers a BIG IoT API as a generic interface to smart object platforms and a
marketplace to trade access to IoT data and services across IoT platform and domain boundaries. To demonstrate the solutions offered by the BIG IoT ecosystem use cases based on
different smart object platforms, services and applications will be defined, implemented and
validated in three regional pilots.
The purpose of this deliverable is to document the work carried out in the first iteration
phase of WP 2, Task 2.2 Use case definition and Open call. It defines the guiding use cases
for the BIG IoT ecosystem and for services and applications that will be implemented in the
pilots making use of the BIG IoT API and marketplace.
1.1
Scope of this Document
This deliverable D2.2.a offers an inventory of the use cases for multi-deployable services and
applications that are going to demonstrate and validate the BIG IoT concept of interoperability. The use cases defined in this deliverable set the baseline for the upcoming realization
and implementation of services and applications in the pilots (WP 5) to be provided through
the BIG IoT API (WP 3) and Marketplace (WP 4).
Following the agile approach of BIG IoT, D2.2.a provides a preliminary list of use cases that
will be revised in the second and third iteration phase of the project. Thus, the document
will be updated in two further iteration steps reflecting the overall state of work in the project and the expected contributions of the upcoming open call (D2.2.b) to gradually extend
and complement the service and application portfolio of BIG IoT project.
The deliverable describes an initial set of the basic use cases addressing IT-stakeholder´s
needs to make active use of the future BIG IoT ecosystem (BIG IoT API and Marketplace). The
full picture of ecosystem use cases describing the full range of use cases in detail will be
elaborated and documented after the overall BIG IoT architecture (WP 2, Task 2.4) has been
finalized (M 12 of the project).
The main focus of this document is the definition of use cases derived from regional pilots
making use of technical infrastructure locally available and addressing specific mobility challenges in the pilots.
© 2016
7
DELIVERABLE 2.2.A USE CASE DEFINITION
1.2
D 2.2.A
Executive Summary
D2.2.a provides an overview on the use cases that are relevant to demonstrate interoperability of platforms, and reports on the definition of use cases. This groundwork has been
taken place in two key areas, the BIG IoT ecosystem and the BIG IoT pilots in Northern Germany, Piedmont and Barcelona.
For the BIG IoT ecosystem, use cases have been chosen as most relevant that are supported
by a clear business case and monetary benefits for the key stakeholders and lower the barrier for developers and providers to join the ecosystem. The BIG IoT ecosystem use cases
included in this document are an initial set of use cases reflecting the state-of-work in the
ongoing definition of the final architecture of the BIG IoT ecosystem. They will be further
elaborated in the next iteration of the deliverable.
The definition of BIG IoT pilot use cases was based on an analysis of smart objects and platform infrastructure available in the pilots. To ensure that the pilot use cases meet relevant
future mobility challenges important use case topics have been discussed with local administration and other institutions involved in mobility planning.
As a result of the pilot discussion the deliverable D2.2.a captures use cases of the following
use case clusters emphasizing mobility challenges: Smart Parking, Smart Traffic Management, Public Transport Optimization, Healthy Bike Navigation, Smart Bike Sharing, IncentiveBased Green Route Planning, Multimodal Route Optimization, and Smart Charging as well as
Device-to-Device use cases.
Special emphasis was put on setting-up use case scenarios that illustrate the envisaged interaction of the fictive users with the future services and applications. Furthermore the use
cases are defined on a technical level indicating smart objects, platforms and their actors
involved, use case stories describing the flow of events and corresponding services. A first
high-level description of the corresponding services initializes the specification work to be
done in the following WP 5 that will additionally define in detail in which iteration phase the
listed use cases will be realized.
© 2016
8
DELIVERABLE 2.2.A USE CASE DEFINITION
2
D 2.2.A
Methodology
In this chapter the methodology for the definition of guiding use cases is described. Due to
different focusses the methodology includes specific descriptions for the definition of use
cases for
·
The BIG IoT ecosystem and marketplace that provide a generic interface and the tools to
exchange data, services and applications across platforms and
·
Three regional pilots (Northern Germany, Piedmont, Barcelona) focusing on technical
solutions for smart mobility and smart road infrastructure.
2.1
Methodology for BIG IoT Ecosystem Use Case Definition
The use cases for the BIG IoT ecosystem described in chapter 3 of this document have been
identified as high-priority for the development of release 1 of the BIG IoT architecture.
After a first collection of relevant use case scenarios for an IoT ecosystem, the team partners
involved in the Ecosystem related tasks selected criteria for prioritizing the scenarios for release 1 of BIG IoT 1.
The following criteria have been chosen as most relevant, as they directly influence the success of establishing a new IoT ecosystem:
·
Use cases that are supported by a clear business case and monetary benefits for the key
stakeholders, and
·
Use case scenarios that lower the barrier for developers and providers to join the ecosystem.
Based on those criteria the initial set of ecosystem use case scenarios for release 1 of BIG IoT
was prioritized.
In a second step all individual use cases of the prioritized scenarios were identified, aligned
and grouped into four ecosystem use case clusters.
Further ecosystem use cases and clusters will be defined at a later stage to drive the architecture work for release 2 and 3 of BIG IoT. They will be further elaborated and documented
in D2.2.b, after the first release of the BIG IoT architecture (Task 2.4) has been finalized.
1
The prioritization was critical as the relevant architecture discussions around the BIG IoT ecosystem started
officially only in M4, and thus only limited time was available.
© 2016
9
DELIVERABLE 2.2.A USE CASE DEFINITION
2.2
D 2.2.A
Methodology for Pilot Use Cases Definition
The pilot sites will demonstrate the usage of the BIG IoT Ecosystem in real life conditions.
Therefore, the pilot use cases must reflect the requirements and assets within the pilot sites
on the one hand and the project´s overall goal of showcasing interoperability on the other
side. A dual methodological approach was used to match those requirements: A first bottom-up perspective in defining the pilot use cases focused on what is available and needed
in the pilots. The second top-down perspective focused on interoperability that is to be
demonstrated within the pilots and across pilots in the project.
Starting from the eight Use Case Clusters mentioned in the Description of Action (DOA) 2, e.g.
“Smart Parking”, “Smart Traffic Management” etc., the pilot sites conducted the following
steps to define the use cases:
(1)
Confirmation of use case clusters as stated in the DOA with respect to organizational,
regulatory and technical feasibility within the pilots.
(2)
Definition of atomic use cases within the use case clusters as small building blocks for
the future implementation and demonstration.
(3)
Ranking of the atomic use cases reflecting the relevance of the use cases for the pilots
and taking into account feasibility aspects such as availability of data, required involvement of external providers or third parties (open call).
(4)
Combining of the atomic use cases from the clusters to cross-clusters and cross-pilots
use case scenarios, focusing on future services and applications used by an end user.
(5)
High level description of services, necessary to implement the use cases in the scenarios.
(6)
Definition of interoperability patterns to demonstrate project’s goals within the pilots
and to check if interoperability patterns aspects are addressed by the use cases.
With finalizing the 6th step, the perspectives of the pilots and the project have been
matched.
2
See p. 10 of the DOA.
© 2016
10
DELIVERABLE 2.2.A USE CASE DEFINITION
2.3
D 2.2.A
Structure of the document
The structure of the document follows the methodological approach described above.
The following Chapter 3 depicts the use cases for the BIG IoT Ecosystem.
Chapter 4 gives an introduction of the three pilot sites Northern Germany, Piedmont and
Barcelona. This section includes a general description of the pilots, relevant use case clusters
as well as smart objects and platforms available for the demonstration.
Chapter 5 summarizes the pilot use cases in the use case clusters and shows the prioritization of the atomic use cases. This captures all the use cases relevant in the three pilots and
shows use cases that are relevant for more than one pilot (so called cross-pilot use cases).
In chapter 6, use case scenarios are defined, representing the user view on future applications or services in a storytelling narrative.
Chapter 7 describes in a first outlook the services related to the use cases. This high-level
service description is the starting point for the upcoming WP 5, Task 5.1 Pilot Specification.
Finally, with chapter 8, the interoperability aspects are defined and matched with the use
case clusters showing which interoperability aspects are potentially addressed by which use
case clusters.
© 2016
11
DELIVERABLE 2.2.A USE CASE DEFINITION
3
D 2.2.A
BIG IoT Ecosystem Use Cases
The following chapter provides an overview of use cases related to the BIG IoT ecosystem.
Therefore, the general objective is presented, affected stakeholders are described and finally
the ecosystem use cases are presented.
3.1
Objective
The BIG IoT project aims at enabling the emergence of cross-platform, cross-standard and
cross-domain IoT services and applications towards building IoT ecosystems. As an example,
a cross-platform IoT application could be developed to access parking data provided by different data sources and IoT platforms, for example from a smart cities’ street parking
system, from commercial parking lot providers etc. The application could discover additional
data sources at run-time, as new IoT platforms providing parking data for the relevant city
become available. Finally, the application could also discover and use different data sources
at run-time when the user visits other cities, as different IoT platforms provide the data in
other cities. Similarly, a cross-platform IoT application for a smarter workplace could be enabled to access the wearable sensors of users to utilize the gathered data for different
purposes, e.g. to monitor the environment at their workplace. The described multi-purpose
of things and data gathered by separate IoT platforms can create great benefits.
In order to ignite such an IoT ecosystem that is cross-platform and open to new providers of
resources – so called offerings - as well as consumers of those, interoperability across platforms needs to be enabled. Once cross-platform interoperability is achieved, this will allow
new applications by combining platforms (e.g. a smart city platform with a parking lot platform) and/or data (e.g. parking information from various platforms and regions), and
applications to work on top of different platforms (e.g. the same application works on top of
a smart city platform in Berlin, in Barcelona and in London).
The goal of the project is to design an architecture that aims at overcoming these hurdles
through (1) an open marketplace as the center of the ecosystem functionalities (e.g. authentication, registration of resources to be offered by a provider (i.e. offerings), discovery of
offerings desired by a consumer, and charging), (2) a common API for offering providers and
consumers to interact with the marketplace and each other, as well as (3) common information models and semantic frameworks for describing and querying offerings via the
marketplace.
© 2016
12
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
Fig. 1 outlines the key components of how the BIG IoT project envisions an IoT ecosystem.
The different IoT platforms give access to various kinds of things. Today they use their own
interfaces, but are now extended with a common interface, the BIG IoT API, which offers the
required set of functionalities for interoperability. Through the common API, it becomes easier to develop software artifacts as clients of different platforms. Among such software
artifacts, within the project it is distinguished between services and applications. While both
are consumers of information or functionalities (offerings), services can also act as providers
of offerings. The offerings of providers are advertised on the marketplace, for consumers to
discover them and to gain access to desired providers.
Fig. 1
IoT Ecosystem Overview
To enable interoperability for IoT platforms on server as well as on device level, the BIG IoT
API offers a well-defined set of functionalities. The key functionalities that need to be part of
the common API are (a) Identity management to enable the registration of offerings, (b) Discovery of offerings according to user defined search criteria, (c) Access to meta-data and
data, (d) Tasking to forward commands to things, (e) Event processing and publish/subscribe
of data streams, (f) Vocabulary management for semantic descriptions of concepts, as well
as (g) Security management including authentication, authorization, and key management.
© 2016
13
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
In order to focus the architecture work towards the project´s vision in the first year, towards
BIG IoT release 1, we first selected and prioritized use case scenarios that are critical to establishing a successful ecosystem. In particular, we prioritized scenarios that are (1)
supported by a clear business case and monetary benefits for the key stakeholders, and (2)
lower the barrier for developers and providers to join the ecosystem. In a second step, we
identified all the relevant use cases for those scenarios and grouped them into four use case
clusters.
In the remainder of this section, we present the actors of the ecosystem use cases, the prioritized ecosystem use case scenarios and the use case clusters. The details of the use case
scenarios are provided in part 1 of the annex.
3.2
Ecosystem Actors
The main actors of the BIG IoT ecosystem are shown in the Fig. 2.
Fig. 2
Actors of the BIG IoT Ecosystem
© 2016
14
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
Next, the short description of the BIG IoT Ecosystem Actors is given:
·
BIG IoT Platform is a smart object platform that implements the BIG IoT API and is enabled to provide its resources, i.e. offerings, in the BIG IoT Marketplace, thus acting as a
BIG IoT Offering Provider.
·
BIG IoT Service is a service that implements the BIG IoT API to provide and access offerings in the BIG IoT Marketplace, thus acting both as BIG IoT Offering Provider and BIG IoT
Offering Consumer.
·
BIG IoT Application implements BIG IoT API in order to access offerings registered in the
BIG IoT Marketplace, thus acting as a BIG IoT Offering Consumer.
·
BIG IoT Core Developer is a developer that develops the core components of the BIG IoT
ecosystem e.g. BIG IoT API, SDK, marketplace and its subcomponents etc.
·
BIG IoT Developer uses the BIG IoT technologies to develop BIG IoT enabled Platforms,
Services and Applications.
·
BIG IoT Service/Application/Platform Provider is an entity that operates (e.g. runs and
administrates) a BIG IoT Service/Application/Platform.
·
BIG IoT Marketplace Provider is an entity that operates BIG IoT marketplace for providing, discovering and trading offerings.
3.3
Ecosystem Use Cases
The following use case scenarios have been prioritized and defined for the first release of
the BIG IoT architecture. Further scenarios will be defined at a later stage to drive the architecture work for release 2 and 3 of BIG IoT. They will be further elaborated and documented
in D2.2.b, after the first release of the BIG IoT architecture (Task 2.4) has been finalized.
Use Case scenarios related to development
The following scenarios have been identified as critical to support developers in the process
of making their IoT platforms, services or applications to join the BIG IoT ecosystem. Thus,
these use case scenarios target developers that a.) extend their IoT platform to support the
BIG IoT API and offer resources on the marketplace, and b.) develop a service or application
which uses the BIG IoT API to gain access to the marketplace to discover offering providers
and connect to the respective platform or service to access the resources.
© 2016
15
DELIVERABLE 2.2.A USE CASE DEFINITION
·
D 2.2.A
BEU-DEV-1: BIG IoT Developer studies the BIG IoT documentation, example code and
downloads the open source SDK: see Annex Part 1 for a detailed description
·
BEU-DEV-2: BIG IoT Service/Platform Developer develops a Service or extends an IoT
Plat-form to register an offering on a Marketplace: see Annex Part 1 for a detailed description
·
BEU-DEV-3: BIG IoT Application/Service Developer develops an Application/Service
which leverages a resource offering provided on a Marketplace: see Annex Part 1 for a
detailed description
Use Case scenarios related to trading of resource offerings on the marketplace
The two scenarios listed here describe how (a) BIG IoT Offering Providers (Services and Platforms) can offer their offerings on the marketplace as well as how (b) BIG IoT Offering
Consumers (Services and Applications) can search for offerings and access them.
·
BEU-RDA-1: BIG IoT Service/Platform registers a resource offering on a Marketplace (–>
Provider Scenario): see Annex Part 1 for a detailed description
·
BEU-RDA-2: BIG IoT Service/Application uses/accesses a resource offering provided via a
Marketplace (–> Consumer Scenario): see Annex Part 1 for a detailed description
Use Case scenarios related to charging and billing
One of the core functionalities of BIG IoT Marketplace is to enable BIG IoT Offering Providers
to monetize the use of their offerings. Therefore, few scenarios describing the collection of
accounting and usage data, as well as further functions necessary for charging and billing are
identified.
·
BEU-CB-1: BIG IoT Platform/Service/Application perform accounting of accessed offerings: see Annex Part 1 for a detailed description
·
BEU-CB-2: BIG IoT Marketplace offers information/functions access to charging information to providers and consumers: see Annex Part 1 for a detailed description
·
BEU-CB-3: BIG IoT Marketplace offers providers and consumers access to billing related
functions/information: see Annex Part 1 for a detailed description
© 2016
16
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
Use case scenario related to core development
The development of the core technologies of the BIG IoT ecosystem will be done as an open
community process as early as possible. Thus we have identified the main use cases necessary for this process.
·
BEU-COREDEV-1: BIG IoT Core Developer develops and documents the BIG IoT Core (API,
Marketplace, ...): see Annex Part 1 for a detailed description
Based on the prioritized use case scenarios, the following four ecosystem use case clusters
were defined. These clusters are used as a basis to focus the definition of the BIG IoT architecture requirements and to scope the architecture work for release 1 of BIG IoT. Note
however that the final decision of what will be implemented as part of release 1 of BIG IoT
will be taken by Task 2.4 as part of the high-level architecture definition by M12 of the project.
Cluster 1:
Use cases related to development of BIG IoT Platforms, Services and Applica-
tions (for Offering Providers and Consumers on the marketplace)
The Fig. 3 depicts the use cases related to the development of new assets of BIG IoT Platform, Service and Application Developers based on the available BIG IoT technologies and
offered resources.
These use cases enable the developers to define required semantic descriptions and queries
for registering offerings on the marketplace, and to discover then respectively. Moreover
the development of BIG IoT enabled assets will be simplified by providing automatically generated snippets of code for BIG IoT calls.
A BIG IoT Marketplace Provider provides composition recipes that can be used for composition of different offerings, thus providing a value add to the marketplace.
© 2016
17
DELIVERABLE 2.2.A USE CASE DEFINITION
Fig. 3:
D 2.2.A
Development use cases
Cluster 2:
Use cases related to registration, discovery and access of offerings on a mar-
ketplace
The use cases related to registration, discovery and access of resources offered on the BIG
IoT marketplace are shown in the Fig. 4. In order for BIG IoT Services, Applications and Platforms to be able to register, discover and access resources they need to be authenticated
and their authorization for these actions need to be verified.
When registering new resource offerings on the marketplace, semantic descriptions need to
be provided based on a common information model. This information model is also used for
semantic querying and composition of offerings.
© 2016
18
DELIVERABLE 2.2.A USE CASE DEFINITION
Fig. 4:
D 2.2.A
Resource registration, discovery and access use cases
Cluster 3:
Use cases related to charging and billing
All use cases relevant for charging and billing are summarized in the Fig. 5. After receiving
valid charging tokens Services and Applications (as Offering Consumers) are able to access
resources provided by Services and Platforms (as Offering Providers). Both sides, consumers
and providers, collect usage data and accounting data respectively, and report them to the
marketplace. These mechanisms are the basis for the BIG IoT Offering Providers to monetize
their resources. Via a Web portal on the marketplace, they are enabled to define the pricing
models, invoice template and schedule etc. BIG IoT Consumers (Services and Applications)
are also able to define their type of contract (prepaid or subscription) and view invoice information.
A BIG IoT Marketplace Provider is in charge of providing means for its customers (offering
providers and consumers) to register, authenticate and authorize on the marketplace. Finally, the Marketplace Provider also receives payments (e.g. a share of the transactions) from its
customers for providing the infrastructure and/or service.
© 2016
19
DELIVERABLE 2.2.A USE CASE DEFINITION
Fig. 5:
D 2.2.A
Charging and billing use cases
Cluster 4:
Use cases related to core development of the BIG IoT ecosystem (i.e. BIG IoT
API and marketplace)
The use cases related to the development of the BIG IoT technologies are summarized in the
Fig. 6. Since the development of BIG IoT technologies will be done in an open community
process, the Core Developers need to be registered on the BIG IoT Core Development Environment. Once registered, they can e.g. create issues, commit source code, deploy and test
their software component, create merge request, provide documentation etc. Depending on
their role, Core Developers responsible to guard the overall development and quality of the
open source project will also be able to accept or reject merge requests proposed by regular
Core Developers.
© 2016
20
DELIVERABLE 2.2.A USE CASE DEFINITION
Fig. 6:
D 2.2.A
Core development use cases
A BIG IoT Developer may, upon using the software components and specifications from the
BIG IoT repository, report bugs, submit requests for the new features and provide feedback.
© 2016
21
DELIVERABLE 2.2.A USE CASE DEFINITION
4
D 2.2.A
Pilot Descriptions
In the following chapter a short introduction to the three pilot sites Northern Germany,
Piedmont (Italy) and Barcelona (Spain) is given. For each pilot site, local conditions are described, followed by addressed use case clusters and an overview of technical systems
relevant for the BIG IoT project.
4.1
Northern Germany Pilot
This pilot involves and connects two northern German cities. The first city is Wolfsburg, located in the center of Northern Germany with 125.000 inhabitants. Wolfsburg is home of
the Volkswagen headquarter, which is the biggest employer and economic force in the region. The second city is Berlin, capital of Germany with more than 3.5 Million inhabitants.
The two cities are linked through the highway A2 in a 240 kilometer distance. ICE-trains link
Berlin´s and Wolfsburg´s main stations in less than 70 minutes.
The aim of the Northern Germany pilot within the BIG IoT project is to provide adaptable
mobility services for traffic participants as well as public administrations that can be implemented in any one city, depending on existing smart city infrastructure and platforms.
Therefore, innovative mobility patterns in the corridor between the two cities shall be fostered. Additionally, reducing parking search traffic and promoting e-mobility is on the
mobility agenda of both cities. In supporting electric cars, Car Sharing, train connections and
other public transport facilities, the pilot also enables environmentally conscious decisions in
road and rail traffic.
The use case clusters that are addressed in the pilot are “Multimodal Route Optimization”
directed at commuters who travel between Berlin and Wolfsburg multiple times a week and
consider train as well as road connections. “Smart Parking” use cases will be implemented in
Berlin, and “Smart Charging” use cases will be implemented in both cities, making use of
innovative parking sensors and live data of charging stations. “Public Transport Optimization” use cases shall support e.g. public transport providers in improving their services in
Wolfsburg.
© 2016
22
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
The usable smart objects in the pilot owned by the project participants as well as third party
smart objects are combined via four different platforms, of which three will be BIG IoT enabled (VMZ TIC, Bosch Smart City and Bosch Bezirk). Via 20 services, 32 pilot use cases are
addressed within the four use case clusters mentioned above.
The following Fig. 7 depicts the technical overview of the Northern Germany Pilot.
Fig. 7
Northern Germany Pilot – Technical Overview
© 2016
23
DELIVERABLE 2.2.A USE CASE DEFINITION
4.2
D 2.2.A
Piedmont Pilot
This pilot involves two cities in Piedmont region of Northern Italy. Both cities have a population of about 45.000 inhabitants but have a different economic background and geographic
location.
Biella, with a long history of economic wealth due to the textile industry - unfortunately now
declining - lies in the foothills of the Alps. Over the years Biella has created an integrated
area with suburban villages which share public transport lines and roads. As most Italian
municipalities, Biella has an historical center of town with traffic restrictions that extend
throughout the day and weekends.
Vercelli is situated in the plain of the river Po and it is an important center for the cultivation
of rice. Being surrounded by rice paddles which are flooded from spring through summer,
Vercelli suffers with cold and foggy winters followed with oppressive heat during summer
months. These conditions highly influence the air quality in town that is currently measured
with two official stations belonging to the regional environmental agency ARPA and do not
cover satisfactorily the whole territory. On the other hand, while the expansion of Vercelli
area has not reached neighboring villages, the flat land is favorable for alternative transport
means like bicycle. Last but not least the center of town is subject to traffic and parking restrictions 24 hours a day.
Biella and Vercelli are about 50 km apart and there is no interconnecting highway as well as
no strong economic relationship between the two towns.
The aim of Pilots in Piedmont region is to improve the awareness of citizens and public administrations on environmental and mobility management through the expansion of existing
© 2016
24
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
monitoring infrastructures and integration with modern algorithms of people density estimation.
The use case clusters addressed in these pilots are "Smart Parking" aimed at improving
search time for a free stall and therefore reducing pollution. The latter condition will be
monitored through low-cost air quality stations especially for promoting "Healthy Bike Navigation" and "Smart Bike Sharing" as well as providing local Public Administrations a view on
real-time environmental situation overlaid to traffic flow in "Smart Traffic Management".
Citizens will also be involved in an "Incentive-based Green Route Planning" (through the assignment of virtual incentives) whose aim is to observe the impact on pollutants distribution
by systematically re-routing vehicular traffic on different routes.
The following diagram shows the actors and devices addressed, as well as the smart objects
and platforms involved.
Fig. 8
Piedmont Pilot – Technical Overview
© 2016
25
DELIVERABLE 2.2.A USE CASE DEFINITION
4.3
D 2.2.A
Barcelona Pilot
The pilot takes place in Barcelona, a smart city reference worldwide. Barcelona has more
than 1.600.000 inhabitants (over 3 million in the Barcelona metropolitan area) and hosts
relevant International IT events such as Smart City World Congress, Mobile World Congress
or IOT Solutions World Congress.
The Pilot activities will mainly involve L’Eixample (main Business District with 16% of total
city population) and Les Corts district (an area where different innovative ICT solutions are
available). Both of them are high density urban areas challenging environmental problems
caused by traffic.
The use case clusters that will be addressed in the pilot are
“Smart Parking”, to help citizens finding parking spaces in a
more efficient way to reduce the volume of agitated traffic,
“Smart Traffic Management”, supporting traffic managers to
efficiently use the information elaborated from smart objects, and “Incentive Based Green Route Planning”, to
engage citizens in contributing to keep city environment. An
additional Use Case cluster “Device-to-Device Communication” was also identified and will be further developed in
future releases of this deliverable.
Three BIG IoT enabled platforms will be used in the pilot: OpenIoT (provided by NUIG), Bezirk device-level platform (provided by Bosch) and WorldSensing platform integrated
through a BIG IoT gateway.
Smart Objects available for the pilot will be: 2 SEAT connected cars sending position, & air
quality data (CO, NO2); Traffic detectors for speed or car count (3 magnetometers and 90
Bluetooth Wi-Fi antennas provided by WorldSensing); 600 Parking spot sensors from
WorldSensing currently installed at Les Corts district.
© 2016
26
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
Emulation of connected cars and loop detectors provided by UPC simulation models will
provide synthetic data to be used during early development stages and to support testing
BIG IoT services with large penetration of IoT.
Access to Barcelona City Council real-time data through SENTILO platform will also be enabled on demand (i.e. Noise city sensors).
The following diagram shows the actors and devices addressed, as well as the smart objects
and platforms involved.
Fig. 9
Barcelona Pilot – Technical Overview
© 2016
27
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
5
Pilot Use Case Clusters and Use Case Descriptions
5.1
Overview Use Case Cluster
The following chapter summarizes the use cases considered within the pilots. Therefore,
nine use case clusters are outlined. For each use case cluster, the overall objective is mentioned, associated use cases are summarized within a table and a technical overview shows
the smart objects, platforms and devices envisaged to be used in the clusters.
Starting point for the definition of pilot use cases is the use case overview already inserted in
the Description of Action (DOA) which indicated the use cases relevant for the pilot in
Northern Germany (NG), Piedmont (PIE) and Barcelona (BCN) 3. This initial definition included
use cases from seven topics “Smart Parking”, “Smart Traffic Management”, “Public Transport
Optimization”, “Healthy Bike Navigation”, “Smart Bike Sharing”, “Incentive-based Green
Route Planning” and “Multi-modal Route Optimizer”.
In a very first step, this table has been discussed with stakeholders, platform providers and
city administrations in the pilots to ensure that the smart objects and platforms needed are
available and to confirm that the use cases address mobility topics relevant for the cities. As
an outcome the use case clusters already mentioned in the DOA have been confirmed.
Furthermore, the new use case cluster “Smart Charging” has been added for the Northern
Germany pilot. This reflects the increasing relevance of e-mobility in the cities of Berlin and
Wolfsburg and makes use of the increasing number of e-Charging stations as smart objects
to be included in BIG IoT.
Apart from that an initial definition of the use case cluster “Device to DeviceCommunication” has been added. This use cases cluster support direct interaction between
BIG IoT enabled devices (e.g. BEZIRK enabled mobile phone or Raspberry Pi). It has been
identified as a clear candidate for open calls and hackathons and will be updated on next
releases.
The following table lists the use case clusters and indicates by color highlighting in which
pilot sites the use case clusters are relevant for future implementation.
3
See DOA, p. 10.
© 2016
28
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
Use Case Cluster
Pilot
NG
BCN
PIE
Smart Parking (see 5.2)
Smart Traffic Management (see 5.3)
Public Transport Optimization (see 5.4)
Healthy Bike Navigation (see 5.5)
Smart Bike Sharing (see 5.6)
Incentive-based Green Route Planning (see 5.7)
Multi-modal Route Optimizer (see 5.8)
Smart Charging (see 5.9)
Device-to-Device-Communication (see 5.10)
Blue highlighting indicates relevant use case clusters for the specific pilots.
Tab. 1 Relevant Use case clusters in pilots
Use cases were prioritized by the pilot sites. High priority use cases are highlighted in the use
case table. They are envisaged to be implemented by the pilots during the project. Other use
cases may be implemented in later stages, via the open call or due to technical or regulatory
boundaries not during the project.
The following description of the use case cluster includes
·
Description of the overall objectives of the use case clusters
·
The cluster´s use cases which are relevant in the different pilots
·
A graphical overview on the use case clusters.
A detailed description of the above mentioned use cases indicating smart objects and platforms involved, stakeholders and their benefits as well as the flow of events and services
involved is included in the template of Annex Part 2 of the document.
© 2016
29
DELIVERABLE 2.2.A USE CASE DEFINITION
5.2
D 2.2.A
Smart Parking (SP)
“Smart Parking” is the only use case cluster to be applied in all three pilot sites and showcases interoperability on a European level. It demonstrates parking related data sourced locally
and service provision via the BIG IoT API in all three pilots.
SP use cases offer effective navigation to parking spots based on availability and distance,
taking into account the current traffic conditions and parking prices. This involves new parking spot observing smart objects.
SP services are highly transferable cross-pilot and can be developed for private end users as
well as public administrations.
The services include Parking Spot Availability, Prediction of Parking Spot Availability, Parking
Reservation, Route to Parking Spot, Check-in / Payment and Check-out / Payment as well as
Parking Enforcement. 4
The following table shows the relevant use cases within the use case cluster Smart Parking.
Use cases ranked with high priority for implementation are highlighted in light blue.
Smart Parking Use Cases
NG-Pilot
BCN-Pilot
PIE-Pilot
Find Free Parking Spot (App based)
SP-NG-01
SP-BCN-01
SP-PIE-01
Find Free Parking Spot (with Car integration)
SP-NG-02
Predict Parking Space Availability
SP-NG-03
Find Probable Parking Area
SP-BCN-02
Reserve Parking Spot
SP-NG-04
SP-BCN-03
Route To Parking Spot
SP-NG-05
SP-BCN-04
Check-in
SC-BCN-05
Check-out
SP-BCN-06
Pay for Stay
SP-NG-06
Monitor Parking Spot Area From Desk
SP-NG-11
Monitor Parking Spot Area On Street
SP-NG-12
SP-PIE-04
SP-BCN-07
SP-PIE-12
Monitor Parking Spots, App based
SP-PIE-20
High priority use cases are highlighted in blue.
Tab. 2 Use Cases in Use Case Cluster Smart Parking
4
Use cases and services for public administrations focusing on enforcement are subject to current political
guidelines and require intensive approval procedures. Therefore, use cases addressing enforcement activities
may be technically realized as a prototype in a future iteration phase. An in-situ demonstration of the use case,
however, is out of project scope.
© 2016
30
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
Fig. 10 Overview Use Case Cluster: Smart Parking
© 2016
31
DELIVERABLE 2.2.A USE CASE DEFINITION
5.3
D 2.2.A
Smart Traffic Management (STM)
Traffic Information Center Operators will be able to get information and to monitor abnormal conditions related with traffic status or pollution, based on real time data obtained by
different devices (e.g. air quality sensors of smart cars, low cost air quality stations, WIFI/BT
detectors, etc.).
On the basis of traffic and environment monitoring, traffic recommendations will be issued
to improve city conditions and reduce pollution.
The services include Traffic Monitoring, Traffic Recommendations Management and Environment Monitoring.
The following table shows the relevant use cases within the use case cluster Smart Traffic
Management. Use cases ranked with a high priority for implementation are highlighted in
light blue.
Smart Traffic Management [STM]
NG-Pilot
Smart Net Balancing
STM-NG-01
Get Traffic Information
Monitor Traffic Alarms
Get Travel Times between two points
Monitor Environment Alarms
Set Environment Recommendations
Get Environment Recommendations
Get Air Quality Conditions
Analytic Services for Traffic Management
High priority use cases are highlighted in blue.
BCN-Pilot
PIE-Pilot
STM-BCN-01
STM-BCN-02
STM-BCN-03
STM-BCN-04
STM-BCN-05
STM-BCN-06
STM-PIE-01
STM-PIE-02
STM-PIE-04
STM-PIE-03
STM-PIE-05-09
Tab. 3 Use Cases in Use Case Cluster Smart Traffic Management
© 2016
32
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
Fig. 11 Overview Use Case Cluster: Smart Traffic Management
© 2016
33
DELIVERABLE 2.2.A USE CASE DEFINITION
5.4
D 2.2.A
Public Transport Optimization (PTO)
The target of this use case cluster is to optimize public transportation, both from the perspective of the public transport user, but also from an administrative point of view. This
means that both the usage of public transportation is optimized, in terms of selection and
guidance, and the assignment of resources in public transport system. This is done based on
information about the users of the transport systems, particularly the number of users. This
information is extracted from different systems, depending on availability. But also live information about location of e.g. buses is provided to users to enhance the public
transportation experience.
The services include People Density Estimation on Bus, People Density Estimation in Area
and Live Bus Position; Multimodal Routing.
The following table shows the relevant use cases within the use case cluster Public Transport
Optimization. Use cases ranked with high priority for implementation are highlighted in light
blue.
Public Transport Optimization
NG-Pilot
Optimize public transport resources
PTO-NG-01
Optimize public transport selection/guidance
PTO-NG-02
Optimize end-user experience when arriving at public PTO-NG-03
transport stop
Optimize end-user experience when taking public PTO-NG-04
transport
Live bus tracking
PTO-NG-06
People density estimation based on smart buses
PTO-NG-07
Identification of people flow along bus line
PTO-NG-08
Creating a model for prediction of bus utilization
PTO-NG-09
High priority use cases are highlighted in blue.
BCN-Pilot
PIE-Pilot
Tab. 4 Use Cases in Use Case Cluster Public Transport Optimization
© 2016
34
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
Fig. 12 Overview Use Case Cluster: Public Transport Optimization
© 2016
35
DELIVERABLE 2.2.A USE CASE DEFINITION
5.5
D 2.2.A
Healthy Bike Navigation (HBN)
The target of this use case cluster is to provide bikers with information about healthier alternative routes. The new path is computed taking into account real-time data coming from
low cost air quality stations and traffic conditions as observed by traffic counting sensors.
Points of interest where environmental data is collected (air quality, traffic) are agreed with
the local authorities according to the location of bike paths, crossroads with heavy traffic,
bike sharing stations and more.
The services include Environmental Monitoring and Routing (which in turn reads traffic sensors). The following table shows the relevant use cases within the use case cluster Healthy
Bike Navigation. Use cases ranked with high priority for implementation are highlighted in
light blue.
Healthy Bike Navigation
NG-Pilot
Find Healthier Route
Navigate to Destination through
Healthier Route
High priority use cases are highlighted in blue.
BCN-Pilot
PIE-Pilot
HBN-PIE-01
HBN-PIE-02
Tab. 5 Use Cases in Use Case Cluster Healthy Bike Navigation
Fig. 13 Overview Use Case Cluster: Healthy Bike Navigation
© 2016
36
DELIVERABLE 2.2.A USE CASE DEFINITION
5.6
D 2.2.A
Smart Bike Sharing (SBS)
Through this use case, bike sharing users will be able to gather additional information on the
service based on external sensors. Bikes and docks availability at a given point in time and
space will be provided both with real-time data as well as estimated through historical usage
data.
The services include Dock and Bike Availability Service, and Dock and Bike Estimation Service. The following table shows the relevant use cases within the use case cluster Smart Bike
Sharing. Use cases ranked with high priority for implementation are highlighted in light blue.
Smart Bike Sharing
NG-Pilot
Docks availability
Estimate bike availability
Estimate open dock availability
Locate bike
High priority use cases are highlighted in blue.
BCN-Pilot
PIE-Pilot
SBS-PIE-01
SBS-PIE-02
SBS-PIE-03
SBS-PIE-04
Tab. 6 Use Cases in Use Case Cluster Smart Bike Sharing
Fig. 14 Overview Use Case Cluster: Smart Bike Sharing
© 2016
37
DELIVERABLE 2.2.A USE CASE DEFINITION
5.7
D 2.2.A
Incentive-Based Green Route Planning (GRP)
The objective of this Use Case Cluster is to incentive drivers to follow recommendations in
order to improve city environment, as for example avoiding driving in polluted areas, using
public transport, etc.
Air quality parameters will be monitored through different hardware depending on the Pilot
region showing the interoperability introduced by BIG IoT: low cost air quality stations, air
quality sensors on connected cars and existing noise sensors. Traffic data comes from heterogeneous sources as well, depending on the selected area.
Participating users that follow suggested green routes through the use of an App will collect
points in a virtual ranking on a local scope.
The services include Routing and Incentive Management.
The following table shows the relevant use cases within the use case cluster Incentive-Based
Green Route Planning. Use cases ranked with high priority for implementation are highlighted in light blue.
Incentive-Based Green Route Planning
Find Green Routes
Get Alternative Transport modes
Follow Green Recommendations
High priority use cases are highlighted in blue.
NG-Pilot
BCN-Pilot
GRP-BCN-01
GRP-BCN-02
GRP-BCN-01
PIE-Pilot
GRP-PIE-01
GRP-PIE-02
GRP-PIE-03
Tab. 7 Use Cases in Use Case Cluster Incentive Based Green Route Planning
© 2016
38
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
Fig. 15 Overview Use Case Cluster: Incentive-based Green Route Planning
© 2016
39
DELIVERABLE 2.2.A USE CASE DEFINITION
5.8
D 2.2.A
Multimodal Route Optimization (MRO)
Multimodal Route Optimization is geared to long distance commuters, based on real time
data on public and individual transport and availability of e-charging stations on the corridor
between larger cities. It demonstrates the connection of different data sources for seamless
mobility towards a chosen destination, offering multimodal options and alternative routes in
case of disruptions along the preferred route.
Its services use data from different platforms and make them accessible through the BIG IoT
API. They can be further advanced by connecting other clusters such as Smart Parking.
The services include Multimodal Routing, Personalization, Route Monitoring, Detour / Mode
Shift Recommendation, Incident Notification and Car Sharing Reservation.
The following table shows the relevant use cases within the use case cluster Multimodal
Router Optimization. Use cases ranked with high priority for implementation are highlighted
in light blue.
Use Case Name
NG-Pilot
Initial Routing Start to Destination
MRO-NG-01
Save Route
MRO-NG-02
Monitor Street Traffic Situation
MRO-NG-03
Monitor Rail Situation
MRO-NG-04
Detour
MRO-NG-05
Find Alternative Car
MRO-NG-06
Reserve Alternative Car
MRO-NG-07
Check State of Relations/Route
MRO-NG-08
Inform Commuter about Deviation
MRO-NG-09
High priority use cases are highlighted in blue.
BCN-Pilot
PIE-Pilot
Tab. 8 Use Cases in Use Case Cluster Multimodal Route Optimization
© 2016
40
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
Fig. 16 Overview Use Case Cluster: Multimodal Routing Optimization
© 2016
41
DELIVERABLE 2.2.A USE CASE DEFINITION
5.9
D 2.2.A
Smart Charging (SC)
“Smart Charging” will be demonstrated in the Northern Germany Pilot making use of smart
objects (e-charging stations) that are available in both pilot sites (Berlin and Wolfsburg).
It aims at providing information on available charging stations and provides routing to charging infrastructure currently offered in each city individually as well as including charging
infrastructure in the corridor. The services can be developed for private end users as well as
public administrations.5 The services include Charging Station Availability, Routing to Charging Station, Reserve Charging Station as well as Charging Enforcement.
Smart Charging Use Cases
Find Free Charging Station
Reserve Charging Station
Route To Charging Station
Pay For Charge
Observe Charging Infrastructure From Desk
Observe Charging Infrastructure On-Street
High priority use cases are highlighted in blue.
NG-Pilot
SC-NG-01
SC-NG-02
SC-NG-03
SC-NG-04
SC-NG-11
SC-NG-12
BCN-Pilot
PIE-Pilot
Tab. 9 Use Cases in Use Case Cluster Smart Charging
Fig. 17 Overview Use Case Cluster: Smart Charging
5
Use cases and services for public administrations focusing on enforcement are subject to current political
guidelines and require intensive approval procedures. Therefore, use cases addressing enforcement activities
may be technically realized as a prototype in a future iteration phase. The demonstration of the use case, however, will be beyond project lifetime.
© 2016
42
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
5.10 Device to Device Communication (D2D)
This use case cluster will support direct interaction between BIG IoT enabled devices (e.g.
BEZIRK enabled mobile phone or Raspberry Pi). An initial definition is included in this deliverable, which will be updated and further developed on next releases, as this has been
identified as a clear candidate for open calls and hackathons.
Two use cases have been initially defined to allow interaction between pedestrian or bikers
and smart traffic lights.
Smart Charging Use Cases
NG-Pilot
Pedestrian – Traffic Light Interactions
Cycler – Traffic Light Interactions
High priority use cases are highlighted in blue.
BCN-Pilot
D2D-BCN-01
D2D-BCN-02
PIE-Pilot
Tab. 10 Use Cases in Use Case Cluster Device 2 Device
A preliminary description of the above mentioned use cases indicating smart objects and
platforms involved, stakeholders and their benefits as well as the flow of events and services
involved is included in Annex Part 2 of the document.
Fig. 18 Overview Use Case Cluster: Device to Device
© 2016
43
DELIVERABLE 2.2.A USE CASE DEFINITION
6
D 2.2.A
Use Case Scenarios
After having defined use cases in the preceding chapters the next step is to show how the
defined use cases can be addressed in future applications. Therefore, this chapters outlines
use case scenarios that focus on a fictive user/actor and illustrate how this user/actor will
interact with a future application.
The following description of use case scenarios is done for
·
Pilot specific use case scenarios merging use cases of different clusters in pilot-specific
user stories. This is done to show the diversity of use cases based on different smart objects and platforms available in the local sites that can be potentially implemented in
future pilot-specific applications.
·
Cross-pilot use case scenarios addressing use cases implemented in various pilot sites to
outline cross-pilot interoperability in future applications.
6.1
Northern Germany Pilot
6.1.1 Commuter Berlin <-> Wolfsburg
Actor: Benjamin Big
• Role: Frequent Commuter
• Residence: Berlin
• Working in Wolfsburg
Benjamin Big works as a freelancing vehicle engineer for VW and WAG. As a frequent commuter, Benjamin usually boards the ICE, departing at Berlin-Main Station at 07:49am. The
train allows him to attend the regular morning meetings at the Wolfsburg Mobility Station at
09:30am as well as checking his e-mails and preparing for the meeting ahead whilst on the
way.
Since he needs to commute between Berlin and Wolfsburg at least 3 times a week, he experiences short notice delays, cancellations and changes of schedule quite often and checks in
advance whether any disruptions might cause him to change his travel route. This could
mean opting for a later, an earlier or even a different train connection but also choosing his
car instead of public transport.
© 2016
44
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
As possible disturbances are manifold, Benjamin was looking for an easier way to keep track
on his options and discovered the BIG IoT Commuter App.
After downloading the app and creating a personalized user profile he tries the app by entering his three-times-a-week return trip from Berlin-Mitte to Wolfsburg Mobility Station
[MRO-NG-01]. From the modal and multi modal routing results the app provided, Benjamin
selected two recommendations to be saved in his personal account [MRO-NG-02]:
1. His preferred connection with his own electric car to Berlin-Main Station, with Deutsche
Bahn (DB) to Wolfsburg Main Station and from there to the Mobility Station via electric
Carsharing car.
2. His alternative connection with his own car via highway A2, from Berlin to Wolfsburg.
Today, Benjamin has to attend a regular meeting in Wolfsburg regarding the upcoming release of a new range of electric cars. The meeting starts at 9.30am.
The Alarm goes off at 06:30 in the morning which gives him enough time to get ready and
catch his usual train at 07:49am. Via push-message the app notifies him [MRO-NG-09] that
the trains are running on time and no disruptions can be detected along the corridor to
Wolfsburg [MRO-NG-04] as well as on his preferred route to the Berlin Main Station [MRONG-03].
While having his morning coffee, Benjamin remembers that his car needs charging. He opens
the app again and looks for available parking spots with charging infrastructure close to the
main station. The system checks, based on parking spot detection, which parking spots are
currently free (and for which no reservations are pending for the requested timeframe); [SCNG-01]. He finds a spot that is available until his return at 5 pm and reserves it straight away
[SC-NG-02] so he can focus on driving while being routed by the app [SC-NG-03]. Once he
arrives at his reserved sparking spot, he plugs his car in to the charge column and proceeds
to the station.
His train arrives on time and Benjamin continues his journey to Wolfsburg. While on the
train he has time to check on Wolfburg´s bus schedule to get from the station to his meeting
venue. He finds a bus route that stops close to his destination. It´s due to depart shortly after his train´s arrival so he hurries al little to catch it and he arrives right on time for the
meeting to begin.
After a productive 4 hour meeting he uses public transport to get to Wolfsburg Main Station.
As a passenger that regularly uses public transport he opens an app, where he is presented
with a list of bus lines of Wolfsburg. He selects the bus line of interest, and is presented with
a list of stops and a map. He selects a bus stop of interest. From this he can see live infor-
© 2016
45
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
mation about the next bus arriving at the selected stop [PTO-NG-02]. This information include indication of where the bus currently is located, if the bus is delayed, an indication of
the number of people on the bus, and a forecast of the number of people on the bus when it
reaches his stop [PTO-NG-06]. Based on this information he can choose if he takes this bus, if
he should switch to take another line, a later bus, or another mode of transportation.
He can also choose to see historical information about the number of people on the bus
based on location and time of day. This will allow him to plan ahead, e.g. if he wants to avoid
over filled buses he can see at which times of the day the buses are less loaded [PTO-NG-09].
While using the public transport he connects with a smart device on the bus to get real time
information about public transport connections [PTO-NG-04]. When waiting for a bus at the
bus stop, he can also connect to a smart device at the bus stop to get live information relevant to the current location [PTO-NG-03].
One quick look at the app [MRO-NG-08] shows him that the next train arriving will be on
time and no difficulties along the track have to be expected [MRO-NG-04].
After his arrival at the Berlin main station and returning to his own car he pays [SC-NG-04]
for the day´s charging fee. Docking his phone onto the dashboard of his car, the app notifies
[MRO-NG-09] Benjamin of a road block on his preferred route home [MRO-NG-03] and offers an alternative [MRO-NG-05].
© 2016
46
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
6.1.2 E-Mobility User
Actor: Benjamin Big
• Role: Electric car user
• Residence: Berlin
• Working in Wolfsburg
In the morning of another day, the app notifies him [MRO-NG-09] of major delays in the ICE
schedule [MRO-NG-04], so he uses his alternative connection by car. He checks for any troubles along his route [MRO-NG-03; MRO-NG-08] before his departure. As his electric car is
fully charged he will only have to recharge during his meeting in Wolfsburg.
Using the app he finds charging infrastructure close to the meeting venue [SC-NG-01] that
will be available for the duration of the meeting. So he reserves it [SC-NG-02] to ensure that
he can use it and return to Berlin without delays.
After the meeting Benjamin pays the charging fee [SC-NG-04] and checks again, if any disruptions along his preferred route are to be expected [MRO-NG-03; MRO-NG-08]. Since the
highway is clear of any traffic jams or construction sites, his journey home passes uneventfully.
6.1.3 Parking Enforcement Officer
Actor: Karl Müller
• Role: Parking Enforcement Officer
• Residence: Berlin
• Working for District Administration
Karl Müller is a Parking Enforcement Officer, employed by the Public Administration. He supervises the operation status of charging stations and issues parking tickets in case of
parking violation and for vehicles parked at charging stations and not charging.
When on duty, Karl usually reviews both the charging infrastructure and the parking spots
simultaneously. So on office days, after starting his desktop PC and going through his routines, he opens the BIG IoT App/Program and monitors the parking and charging spots [SPNG-11; SC-NG-11].
© 2016
47
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
A colleague who is working on-site that day would sometimes call to verify a case before
making a decision. As the colleague is equipped with a handheld device featuring the same
monitoring app/program [SP-NG-12; SC-NG-12] Karl uses at his desk they share the same
information and can easily come to one conclusion.
6.1.4 Public Transport Manager
Actor: John Bender
• Role: Public Transport Manager
• Residence: Wolfsburg
• Has to optimize usage of PT fleet
John Bender is an employee at the public transport company in Wolfsburg and has a number
of various tasks related to resource management of public transport and to monitor the live
status of buses. On a monthly basis he must evaluate if the usage of transport resources can
be optimized, specifically in terms of if there are routes with too few buses or too small buses, or if there are routes where at certain times the buses are mostly empty. He does this by
going to a web page where he is presented with a list of the bus routes in the city. He clicks
on one bus line, and is presented with a number of graphs. Each graph represents the number of people registered on the bus over time, so from early morning to late night. He clicks
on one graph that corresponds to the people counted by one sensor on one bus, to get a
more detailed view. He clicks on a point on the graph where the number of people is low.
The geographical location of the bus corresponding to the selected point on the graph is
now presented on a map.
Based on this information he can choose to put in a bigger or smaller bus, or perhaps put in
an extra bus at specific times of the day [PTO-NG-01; PTO-NG-09].
On a daily basis he is tasked with monitoring the live status of the buses, both in terms of if
the buses do not follow the schedule, and in terms of the load of people on the buses.
He does this by looking at the same web page and selecting a live view. Here he is presented
with a map where it is indicated where the buses are located currently. He can now choose
to filter for a specific route, which will present him only with the locations of the relevant
buses, and their route and where they are currently supposed to be [PTO-NG-06].
© 2016
48
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
6.1.5 Public Transport Optimizer
Actor: Jane Jenner
• Role: Public Administration Employee
• Residence: Wolfsburg
• Plans Public Transport Network
Jane is an employee of the city, working with urban planning, and is tasked with optimizing
different services provided by the city, e.g. public transport and stops, waste collection,
street cleaning, police patrolling, etc.
To do this she must support her knowledge with information about people density in the city
at different times. She obtains this information by opening a web page to see a heat map
showing the people density in the city.
She can also select to see the map as an animation, indicating the people density over the
course of a day. She can now use this information to make informed decisions related to the
task at hand [PTO-NG-07].
In connection with a special city wide event the employee of the city is in charge of the
overall manning, i.e. service staff, police, checkpoints, other. To do this she needs a live
overview of crowd movement in the city to be able to assign or move staff to most relevant
areas.
She opens a web page where she can see the current movement of people. She can choose
how far back in time she wants to have information (e.g. 10 - 60 min), and based on this,
vectors are presented on the map indicating where people are moving from and to.
Based on this she can see if there is a tendency that people are moving through a certain
area, or towards a single point (e.g. a stadium), and act accordingly [PTO-NG-08].
© 2016
49
DELIVERABLE 2.2.A USE CASE DEFINITION
6.2
D 2.2.A
Piedmont Pilot
6.2.1 Public Bike User
Actor: Giuseppe Verdi
• Role: Public Bike User
• Residence: Vercelli
• Uses public bike for daily mobility
Giuseppe Verdi works as a civil employee at the Municipality of Vercelli and every day he
uses a public bike to go to work.
Close to Giuseppe Verdi’s house there are 2 public docks with 9 bikes and every morning, he
uses the app [SBS-PIE-01] to check how many bikes are available in which docks.
Usually there are always 2 or 3 free bikes per dock [SBS-PIE-02], so he can take the public
bike for driving to the office. When he arrives at his office he leaves the bike using the app
[SBS-PIE-03].
The distance between Giuseppe Verdi’s house and his office is 3 km, and he has to cross the
town, but surely he is convinced that this is the greener, healthier and fastest way to go to
work. For this he uses the app [HBN-PIE-01] to verify and to navigate [HBN-PIE-02], following
the better route.
6.2.2 Traffic Control Center Operator
Actor: Elsa Morante
• Role: Traffic Control Centre Operator
• Residence: Biella
• Controls traffic in an environmentally-friendly way
In Biella, Elsa Morante is a traffic manager where she monitors the traffic and the state of air
pollution in the industrial area of the town. For this, she uses the web application that provides information about the congestion of traffic in the busiest crossing points of the city
[STM-PIE-01] and that provides information about the air quality, including the industrial
area [STM-PIE-03].
© 2016
50
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
In case of abnormal traffic situations Elsa receives an alert [STM-PIE-02] and she notifies the
police.
In case of emissions exceeding limit values in the industrial area or in town Elsa Morante
receives an alert [STM-PIE-04] and she notifies the firemen.
6.2.3 Delivery Company Driver
Actor: Alessandro Manzoni
• Role: Delivery Company Empolyee
• Residence: Biella
• Wants to be green and wants to find a parking place
Alessandro Manzoni is a van driver and today he has to leave from Biella to deliver torcetti
(that are the typical cookies of Biella) in Vercelli. To get from Biella to Vercelli it takes 45
minutes, because there is no highway that links the 2 towns. The delivery area in Vercelli lies
within the pedestrian area and is accessible only between 8 and 11 a.m. While he is in Vercelli, Alessandro will visit his uncle who is in the hospital this week for the yearly check-up.
The visiting hours are between 9 and 11 a.m.
Alessandro leaves home at 7 a.m. and goes to the torcetti factory to load the van. For this he
uses the app [GRP-PIE-01] to check the best route and to increase his rank to be the greenest driver of his company. [GRP-PIE-03]
At 7.30 a.m. Alessandro drives from Biella to Vercelli and when he reaches the pedestrian
area entrance he uses the app [SP-PIE-01] to find and to reach [SP-PIE-04] the nearest free
parking spot to deliver his goods.
Alessandro parks the van at 8.30 a.m. and it takes him 30 minutes to deliver torcetti in 2
shops. This is also the average turnaround time of the parking spot [SP-PIE-12].
Alessandro performs delivery and then checks if there are public buses to go to the hospital
taking into account that he can leave his van in the parking stall for at most 1 hour. He verifies that the bus has just passed [GRP-PIE-02] and the next will come in 1 hour.
After that Alessandro checks if there are free parking spots in the hospital area using [SP-PIE20] and he verifies that there is a good turnover so he has a good probability to find free
spots.
© 2016
51
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
The hospital is in the opposite direction of the pedestrian area. To go there, Alessandro
checks the greener route with the app [GRP-PIE-01].
All Alessandro’s movements in the parking spots are monitored in an anonymous way by the
web application that Elsa uses on her desk [SP-PIE-12].
6.2.4 Security and Mobility Operators
Actor: Bice Venco
• Role: Public Security Operator
• Residence: Vercelli
• Public security for city wellbeing
Actor: Arrigo Apiedi
• Role: Smart Monitoring operator
• Residence: Vercelli
• Supervises the city´s pollution levels
Bice Venco is a Public Security Employee working in the city of Vercelli. Saturday morning
she’s monitoring the traffic in the city center when she receives a call from Arrigo Apiedi, a
civil employee working in the monitoring center of Vercelli. Arrigo tells her that an anomalous noise level has been detected in the area of the flea market [STM-PIE-05]. Arrigo also
asks Bice to inspect the area to understand the cause of the noise and verify if any critical
event is happening.
When Bice reaches the flea market, she soon understands why such a noise has been detected. That day, a vintage motorcycles club organized a show connected with the flea
market, where also old spare parts and old style motorcycle clothing are on sale. Some bikers already arrived with their motorcycles.
Bice explains to Arrigo that more than usual people seem to be present although it is still
early morning. Arrigo checks in the Traffic Monitoring System and discovers that more than
usual traffic towards Vercelli is detected in the main roads around the town [STM-PIE-08].
He imagines that the vintage motorcycle show could be an attraction for people who usually
don´t visit the flea market, potentially generating unexpected traffic jams during the day in
the area.
© 2016
52
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
Arrigo verifies the transport mode forecast provided by the Traffic Monitoring System [STMPIE-09] as well as alternative routes provided by the system. Then he contacts the Traffic
Officer of the municipality to organize countermeasures on the roads for leading people to
alternative roads. Extraordinary security staff also has to intervene to help managing the
situation. Thanks to these efforts the impact on the road traffic is contained and people enjoy the flea market and the motorcycle show.
6.3
Barcelona Pilot
6.3.1 Incentives for Connected Car User
Actor 1: Roberto Sala
• Role: Traffic Control Centre Manager
• Residence: Barcelona
• Informs his fellow citizens on traffic and environment
situation and recommends green routes
Actor 2: Susana Ventura
• Role: Traffic Participant, commuter
• Residence: Mataró
• Drives to Barcelona for work
Susana Ventura is a Wildlife biologist and she is commuting in her Connected Car from her
residence in Mataró to her job in Barcelona. Roberto Sala -a Traffic Information Centre Manager- decides to issue a recommendation through the Barcelona Control Centre [STM-BCN05]. While driving, the Traffic Recommendation appears in Susana’s app as it’s affecting her
route to work: “High pollution! Public transport is encouraged” [STM-BCN-06]. She decides
to follow the recommendation. To do that, she has to park and take a bus or the metro so
she uses her app for finding the nearest parking [SP-BCN-01]. She decides which parking to
go to and asks for a route to get there [SP-BCN-04]. When Susana reaches the parking she
checks-in with her app [SP-BCN-05]. Then she asks her phone app for the best public transportation route to her workplace [GRP-BCN-02]. The app tracks her route with public
transport and when she reaches her destination the app gives her some points for following
the green route [GRP-BCN-03].
© 2016
53
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
In Fig. 19 a graphical illustration of the use case scenario is shown.
Susana is driving her Smart Car
through the city of Barcelona
Roberto issues a
Recommendation through the
Barcelona Control Centre
The Recommendation suggests
taking public transportation
When Susana reaches the
parking she checks-in
Her app tells Susana of the
Traffic Recommendation
She decides to follow the city’s
recommendation and asks the
app for the nearest parking.
Then she checks her phone
app for public transportation
to her original destination
The app gives her some
points for following the
green route
The app tracks her route in
order to give her incentives
Good job, Susana!
Fig. 19 Graphical Illustration of Incentives for Connected Car Users
© 2016
54
DELIVERABLE 2.2.A USE CASE DEFINITION
6.4
D 2.2.A
Smart Parking in Northern Germany – Piedmont - Barcelona
Actors: Pol and Isabella
• Role: frequent car users
• Residence: Badalona
• Young urban professionals travelling all over
Europe
Pol and Isabella live just outside Barcelona’s city borders and commute to their workplace in
the city everyday by their own car. As they often meet friends in the evening at different
locations, they regularly use the BIG IoT App to find a parking spot [SP-BCN-01] close to that
day´s venue. Whenever they can, they reserve that space [SP-BCN-03] and let the app route
[SP-BCN-04] them to the destination.
They also like travelling Europe driving their car. So whenever they go on a trip they use the
app at their destination, the same way they would at home, to find [SP-NG-01, SP-PIE-01],
reserve [SP-NG-04] and get routed [SP-NG-05, SP-PIE-04] to the chosen space .
6.5
Smart Traffic Management in Piedmont and Barcelona
Actor 1: Elsa Morante
• Role: Traffic Control Centre Operator
• Residence: Biella
• Wants to control traffic environmentally-friendly
Actor 2: Roberto Sala
• Role: Traffic Control Centre Manager
• Residence: Barcelona
• Informs his fellow citizens on traffic and
environment situation
© 2016
55
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
In Biella, Elsa Morante is a traffic manager where she monitors the traffic and the state of air
pollution in the industrial area of the town. For this, she uses the web application that provides information about the congestion of traffic in the busiest crossing points of the city
[STM-PIE-01] and that provides information about the air quality, including the industrial
area [STM-PIE-03]. In case of abnormal traffic situations Elsa receives an alert [STM-PIE-02]
and she notifies the police. In case of emissions exceeding limit values in the industrial area
or in town Elsa Morante receives an alert [STM-PIE-04] and she notifies the Regional Agency
for the Protection of the Environment (Agenzia Regionale per la Protezione Ambientale ARPA) of Piedmont. ARPA will cross check the information with readings from their expensive (but sparse) instruments, historical series and provide indications on the need to take
corrective actions."
In Barcelona Roberto Sala is a Traffic Manager at the Traffic Information Center. Like every
day, while drinking his morning coffee, he queries the Traffic Application -provided by IceCold Robot Solutions- for information about travel time and speeds in Barcelona to have a
general overview. To do so he selects an area in the city and a color-coded map is shown
[STM-BCN-01]. Then he defines the alarms to be triggered when a low speed threshold is
reached [STM-BCN-02] or when noise levels are too high [STM-BCN-04].
Meanwhile, in Biella, Elsa Morante receives a notification. An air-quality alarm she defined
last fortnight is active [STM-PIE-04] in her Transportation Management Application provided by Ice-Cold Robot Solutions and Greentech Services. She decides to check the status
of the city [STM-PIE-01] and inform the City Council Transport Manager about the situation.
At the same time, a noise pollution alarm for Barcelona City Centre is triggered and shown in
the Traffic Control Centre screen [STM-BCN-04]. Roberto checks travel times in main links of
Barcelona [STM-BCN-03], which are also shown in the website, before defining some traffic
recommendations as for example to avoid the City Centre [STM-BCN-05] in order to reduce
noise levels in that area.
© 2016
56
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
1
3
2
During his day he has the need to
know the status of the city
network
Roberto is on his job as a Traffic
Control Centre Manager
4
5
A map of the area with colourcoded information about travel
time and speed is shown
7
6
He decides to define some
Alarms for Pollution and Speed
in the City Centre
Meanwhile in Biella, Elsa Morante
is on her job
9
8
A notification is pushed
to her application
He selects a specific area in the
city to be queried
The alarm says that the
threshold she defined
has been reached
At the same time,
Roberto is looking at
travel times
11
10
Finally he defines some
traffic
recommendations
Nice job, Elsa and
Roberto!
Fig. 20 Graphical Illustration of Smart Traffic Management in Barcelona and Piedmont
© 2016
57
DELIVERABLE 2.2.A USE CASE DEFINITION
7
D 2.2.A
Services (Outlook)
The following table summarizes services addressed by the Use Cases. Herein mentioned services are candidates for implementation. They may become implemented by the pilots in
one of the three iterations, by an external provider via the Open Call or may be implemented beyond the project term.
The services addressed here are described within a first, high level description in Part 3 of
the annex. The detailed specification of the service as well as a timeline for the implementation of the services will be done in Task 5.1 and will be documented in D 5.1a.
Services can address different use case clusters. In the following table they are listed under
the Use Case Cluster they are most relevant for.
Service Name
Short Description
Smart Parking related Services
Parking Availability
This service will provide information about available parking spots in an
Service
area based on user location or route target.
Route to Parking Spot This service returns a route from a starting point A to a destination B,
Service
taking the availability of a free parking spot at the destination location
into account.
Parking Predictive
This service will give a prediction of the availability of parking lots, based
Service
on information about parking lots, such as current and historical availability, together with information about people density in area of parking
lots.
Parking Reservation
This service will support reserving a parking spot.
Service
Check-in / Payment – Check-In / Check-Out Payment Service will manage new arrivals and deCheck-out / Payment
partures in a parking area. In addition payment procedure will be
Service
handled.
Parking Enforcement
The Parking Enforcement Service aggregates data of parking spot detecService
tors in a way that supports enforcement officers in becoming more
efficient in their work by giving recommendations for observing specific
areas. Therefore, the Service offers information about areas with high
amounts of current violations (e. g. second lane parking, parking in intersections etc.) or high probability of violations (e. g. high current parking
pressure).
Smart Traffic Management related Services
Traffic Monitoring
Smart Traffic Monitoring service will implement data filtering, map
Service
matching (for connected cars data) and estimate traffic variables (i.e.
travel times & speeds).
Environment Monitor- This service collects environmental data from sensors spread on the terriing Service
tory. It may have the ability to issue alarms in the event preset thresholds
are crossed.
© 2016
58
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
Service Name
Traffic Recommendations Management
Service
Analytic Services for
Traffic Management
Short Description
Traffic Recommendations Management Service will provide active recommendations about traffic/environment. These recommendations are
generated in the control center.
The Analytic Services for Traffic Management could provide parameters
to analyze traffic situations such as an O/D Table specifying number of
people moving between a pair of POI/areas, Historical People Density at
POI, People density at POI, Road Traffic information, forecasting vehicular
traffic index expressed in on 4 levels according to DATEX II Data Model
(Free Flow, Heavy, Congested, Impossible), Area Traffic information, forecasting vehicular traffic index expressed in on 4 levels according to DATEX
II Data Model (Free Flow, Heavy, Congested, Impossible), Mobility Patterns, describing common behaviors referring to mobility activities
conducted where, when, with whom and for how long, using what
transport mode and which route, Cross correlation with external data
services, forecasting the phenomena related to the external data source
(external data need to be provided by external data provider).
Public Transport Optimization related Services
People Density EstiService that gives an estimate of the number of people currently on the
mation on Bus Service bus, based on information about Wi-Fi probes emitted by users devices,
collected by sensors on buses.
People Density EstiService that gives an estimate of the number of people currently in an
mation in Area Service area, based on information about Wi-Fi probes emitted by users devices,
collected by sensors on buses.
Live Bus Position Ser- This service gives live information about the location of buses.
vice
Healthy Bike Navigation related Services
Healthy Bike NavigaHealthy Bike Navigation uses services from Smart Bike Sharing cluster.
tion
Smart Bike Sharing related Services
Dock and Bikes Avail- For each Bike Sharing Station, in the selected area, the service returns the
ability Service
actual number of: total docks, available docks and available bikes.
Dock and Bike Estima- This service will give a prediction of the availability of bikes and docks,
tion Service
based on information about docks, such as current and historical availability, together with information about people density in area around bike
sharing station and live bicycle position information.
Incentive-Based Green Route Planning related Services
Routing Service
The service returns the route to follow from point A to point B taking into
account waypoints to avoid because of traffic congestion, pollution or
traffic controller indication.
Incentive ManageThis service handles the collection of points for participating users that
ment Service
follow green recommendations.
Multimodal Route Optimization related Services
Personalization SerThe Personalization Service allows users to store their contact data, prefvice
erences and behavioral data as well as preferred routes on a server for
being actively informed about changes in traffic situations.
Multimodal Routing
For a given Start-Destination Combination and time, the Service returns
Service
the best travelling options for different transport modes.
© 2016
59
DELIVERABLE 2.2.A USE CASE DEFINITION
Service Name
Route Monitoring
Service
Incident Notification
Service
D 2.2.A
Short Description
The Route Monitoring service monitors the actual traffic situation on
precalculated routes (Result of Multimodal Routing Service) and triggers
Incident notification service if high deviations occur (e.g. long delays).
The incident notification service informs an end user (commuter or traffic
participant) about disruptions, service delays or congestions on his predefined routes.
This service is informed about delays on routes and uses the intermodal
router to propose a different travel option.
Detour / Mode Shift
Recommendation
Service
Car Sharing ReservaThis service allows end-users to find and directly reserve a Carsharing car
tion Service
for his route.
Smart Charging related Services
Charging Station
This service will provide information about available charging stations in
Availability Service
an area based on user location or route target.
Routing to Charging
This service returns a route from a starting point A to a destination B,
Station Service
taking the availability of a free charging station at the destination location
into account.
Reserve Charging
This service allows end-users to directly reserve a Charging Station in
Station Service
private area for his route.
Charging Enforcement The Charging Enforcement Service combines data of parking spot detecService
tors with those of charging stations and aggregates them in a way that
supports enforcement officers in becoming more efficient in their work
by giving recommendations for observing specific areas. Therefore, the
Service offers information about areas with high amounts or high potential of current violations (e.g. combustion vehicles parking on charging
station attached parking spots or electric cars parking too long on charging station attached parking spots).
Tab. 11 Services addressed by Use Cases
© 2016
60
DELIVERABLE 2.2.A USE CASE DEFINITION
8
D 2.2.A
Interoperability in Use Cases
As already mentioned in section 2.2, the aspect of interoperability is of specific importance
for defining the BIG IoT use cases. It has to be ensured that the use cases defined for the
pilots are suitable to show interoperability across platforms and pilots. To do this, a definition of the relevant interoperability patterns is needed and provided in the remainder of this
sub-section6. The various aspects of interoperability described in the following were referenced in the pilot use case clusters to show if and to what extent the pilot use case clusters
address the interoperability patterns.
8.1
Project Definition of Interoperability
Interoperability relates to the syntax as well as to the semantics of interfaces. Syntactic interoperability can be reached through clearly defined and agreed data and interface formats
as well as encodings. Semantic interoperability can be achieved through commonly agreed
information models (e.g. defined with ontologies) used as part of the interfaces and exchanged data.
In the following, generic interoperability patterns for IoT ecosystems were identified, that
the project targets to support in order to achieve the goal of lowering market entry barriers
for developers. The five identified interoperability patterns are:
(1)
Cross Platform Access
(2)
Cross Application Domain Access
(3)
Platform Independence
(4)
Platform-Scale Independence
(5)
Higher-level Service Facades
The patterns are described in the following and summarized in Fig. 21.
6
The five interoperability patterns describe the up-to-date state of work and may be modified according to the
overall project development in coming iteration stages.
© 2016
61
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
The first pattern, “Cross Platform Access” (Fig. 21, a), is the fundamental characteristic of an
interoperable IoT ecosystem. The pattern entails that an application or service accesses resources (information or functions) from multiple platforms through the same interface
specification. For example, this can mean that an “air quality monitoring” application would
access multiple air quality related platforms to gather information, e.g. on different air quality indicators, such as NOx, CO, or O3, from separate platforms. The challenge of realizing this
pattern lays in allowing applications or services to discover platforms with relevant information, and enabling platforms that are potentially from different providers to have the
same interface and use the same formats to communicate data.
The second pattern “Cross Application Domain Access” (Fig. 21, b) extends the “Cross Platform Access” pattern. Services/applications access information and functions not only from
multiple platforms, but also from platforms which host information from different verticals
or application domains. As semantic descriptions of the information sources of a platform
can be accessed through the common platform interface (provided by using the BIG IoT API),
the integration of such (originally heterogeneous) data into one service/application becomes
possible. An application that gathers data from different domains, could e.g. access air quality information, such as O3, and traffic monitoring information, such as average speed, to
provide healthy bicycle routes with cleaner air.
The third pattern “Platform Independence” (Fig. 21, c) represents another basic characteristic of an interoperable IoT ecosystem. It entails that the identical application or service can
be used on top of two different IoT platforms (e.g. in different regions). This can be achieved
by allowing an application/service to discover relevant IoT platforms and to interact with the
different platforms in a uniform manner. For example, these can be two deployments of a
“smart parking” service used for two different geographic regions (e.g. Barcelona and London), which have their own platforms with information about parking spots. Realizing
platform independence is particularly challenging, when the information provided by the
two platforms is created by different kinds of things. For example, in case of parking information, the information on spot availability could be generated by radar-based sensors
mounted on street lamp as well as ultrasound-based sensors in the ground.
The fourth “Platform-Scale Independence” pattern (Fig. 21, d) focuses on integrating platforms of different scale. So called server-level platforms are platforms with many devices
connected (e.g. a cloud platform) and typically host a vast amount of data, whereas devicelevel platforms grant direct access to devices (e.g. a mobile device or an edge gateway) and
typically host small amounts of data. By implementing this pattern, the platform hides its
scale towards connecting services or applications. Data from device-level as well as data col-
© 2016
62
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
lected by server-level platforms can be equally used by services/applications. For example,
an application displays information on air quality monitoring to the user (e.g. as visualizations on a map). On the one hand, the application could allow accessing aggregated
information such as the computed air quality index for a certain region from a server-level
IoT platform.
On the other hand, the application may additionally enable to access data directly from air
quality stations (i.e., device-level platforms), e.g. to display time series from unadulterated
data.
Finally, the fifth pattern “Higher-level Service Facades” (Fig. 21, e) extends the interoperability requirements from platforms to higher-level services. The idea is that not only platforms
but also services offer information and functions via the common BIG IoT API. Thereby, a
service acts as a façade towards an IoT platform and accesses the offered information or
functions to provide value-added functionalities. For example, an air quality viewer application can on the one hand access a platform P1 that provides already aggregated air quality
data. On the other hand, the application can access a service that aggregates air quality data
from platform P2, e.g. because P2 does not have the capabilities to perform data aggregation or host long-term time series data.
Fig. 21: The five patterns of interoperability: a) “Cross Platform Access”, b) "Cross Application Domain Access", c) “Platform Independence”, d) “Platform-Scale Independence”, and e) “Higher-level Service Facades”
Pattern
© 2016
63
DELIVERABLE 2.2.A USE CASE DEFINITION
8.2
D 2.2.A
Interoperability Check
To ensure that interoperability is addressed in the pilot use case clusters a first “interoperability check” has been done matching above mentioned interoperability patterns with the
use case clusters in the pilots.
This was done by the pilot leaders and presented and discussed in the project consortium
during the WP2, Task 2.2 session at the plenary meeting in Vienna 26.04.2016. This consideration reflects the current state of work in defining the pilot use cases as well as in defining
interoperability patterns. It may be adapted in the future according to further project progress.
The findings of this preliminary discussion are summarized in Tab. 12. The table indicates the
way how interoperability patterns are addressed by the different use cases clusters in the
pilots. The columns represent the use cases clusters in the pilots. The lines indicate the interoperability patterns.
The blue color points out that matching the interoperability pattern is envisaged by a cluster
use case- in a pilot. Grey-colored cells indicate that the interoperability pattern is currently
not addressed in the pilot use case clusters
For the current state of work it can be stated that
·
all use case clusters target on providing solutions that meet different interoperability
criteria and
·
all interoperability aspects are addressed in different use case clusters relevant for the
pilots.
This indicates that the envisaged pilot use cases clusters and their related use cases are suitable and qualified to support the overall BIG IoT project goal of demonstrating
interoperability.
© 2016
64
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
Use Case Cluster
SP
Interoperability
pattern
NG
PIE
STM
BCN
PIE
BCN
GRP
PIE
BCN
SBS
HBN
PTO
MRO
SC
PIE
PIE
NG
NG
NG
a) Cross-platform
Access
b) Cross
Application
Domain Access
c) Platform independence
d) Platform Scale
independence
f) Higher-level
service facades
Tab. 12 Results of Interoperability Discussion
© 2016
65
DELIVERABLE 2.2.A USE CASE DEFINITION
9
D 2.2.A
Conclusion and Outlook
D2.2.a offers a preliminary list of BIG IoT use cases. The use cases defined meet the overall
requirements to enable interoperability (BIG IoT ecosystem use cases) and to showcase interoperability addressing specific local demands for mobility services (BIG IoT pilot use
cases)
Given the iterative approach of the projects the use case inventory will be extended and
revised in upcoming versions to include requirements for the open call envisaged (D2.2.b)
and to finalize the list of use cases (D2.2.c).
The described BIG IoT ecosystem use cases are an initial set of high-priority use cases. They
will be further elaborated based on the results of the definition of the high-level architecture
(T2.4), which is currently being defined and will be finalized in M12 of the project.
As a result of the pilot discussion the deliverable D2.2.a captures use cases of the following
use case clusters: Smart Parking, Smart Traffic Management, Public Transport Optimization,
Healthy Bike Navigation, Smart Bike Sharing, Incentive-Based Green Route Planning, Multimodal Route Optimization, Smart Charging and Device-to-Device-Communication.
The presented use cases set ground for the following pilot specification (services and applications) that will be done in WP 5. Based on a first ranking of use cases presented in this
document WP 5, Task 5.1 Pilot Specification will provide a refined timeline for the realization of use cases and corresponding services that takes into account the general project
progress and pilot specific plans for the implementation of smart objects and BIG IoT services.
© 2016
66
DELIVERABLE 2.2.A USE CASE DEFINITION
D 2.2.A
Figures and Tables
FIG. 1
FIG. 2
IOT ECOSYSTEM OVERVIEW ......................................................................................................... 13
ACTORS OF THE BIG IOT ECOSYSTEM ........................................................................................... 14
FIG. 3:
FIG. 4:
DEVELOPMENT USE CASES........................................................................................................... 18
RESOURCE REGISTRATION, DISCOVERY AND ACCESS USE CASES................................................... 19
FIG. 5:
FIG. 6:
FIG. 7
CHARGING AND BILLING USE CASES ............................................................................................. 20
CORE DEVELOPMENT USE CASES ................................................................................................. 21
NORTHERN GERMANY PILOT – TECHNICAL OVERVIEW ................................................................. 23
FIG. 8
FIG. 9
FIG. 10
PIEDMONT PILOT – TECHNICAL OVERVIEW .................................................................................. 25
BARCELONA PILOT – TECHNICAL OVERVIEW ................................................................................ 27
OVERVIEW USE CASE CLUSTER: SMART PARKING ......................................................................... 31
FIG. 11
FIG. 12
FIG. 13
OVERVIEW USE CASE CLUSTER: SMART TRAFFIC MANAGEMENT .................................................. 33
OVERVIEW USE CASE CLUSTER: PUBLIC TRANSPORT OPTIMIZATION ............................................ 35
OVERVIEW USE CASE CLUSTER: HEALTHY BIKE NAVIGATION ........................................................ 36
FIG. 14
FIG. 15
OVERVIEW USE CASE CLUSTER: SMART BIKE SHARING ................................................................. 37
OVERVIEW USE CASE CLUSTER: INCENTIVE-BASED GREEN ROUTE PLANNING ............................... 39
FIG. 16
FIG. 17
FIG. 18
OVERVIEW USE CASE CLUSTER: MULTIMODAL ROUTING OPTIMIZATION...................................... 41
OVERVIEW USE CASE CLUSTER: SMART CHARGING ...................................................................... 42
OVERVIEW USE CASE CLUSTER: DEVICE TO DEVICE....................................................................... 43
FIG. 19
FIG. 20
FIG. 21:
GRAPHICAL ILLUSTRATION OF INCENTIVES FOR CONNECTED CAR USERS...................................... 54
GRAPHICAL ILLUSTRATION OF SMART TRAFFIC MANAGEMENT IN BARCELONA AND PIEDMONT .. 57
THE FIVE PATTERNS OF INTEROPERABILITY: A) “CROSS PLATFORM ACCESS”, B) "CROSS
APPLICATION DOMAIN ACCESS", C) “PLATFORM INDEPENDENCE”, D) “PLATFORM-SCALE
INDEPENDENCE”, AND E) “HIGHER-LEVEL SERVICE FACADES” PATTERN ....................................... 63
TAB. 1
TAB. 2
TAB. 3
RELEVANT USE CASE CLUSTERS IN PILOTS .................................................................................... 29
USE CASES IN USE CASE CLUSTER SMART PARKING ...................................................................... 30
USE CASES IN USE CASE CLUSTER SMART TRAFFIC MANAGEMENT ............................................... 32
TAB. 4
TAB. 5
USE CASES IN USE CASE CLUSTER PUBLIC TRANSPORT OPTIMIZATION.......................................... 34
USE CASES IN USE CASE CLUSTER HEALTHY BIKE NAVIGATION...................................................... 36
TAB. 6
TAB. 7
TAB. 8
USE CASES IN USE CASE CLUSTER SMART BIKE SHARING .............................................................. 37
USE CASES IN USE CASE CLUSTER INCENTIVE BASED GREEN ROUTE PLANNING ............................ 38
USE CASES IN USE CASE CLUSTER MULTIMODAL ROUTE OPTIMIZATION....................................... 40
TAB. 9
TAB. 10
TAB. 11
USE CASES IN USE CASE CLUSTER SMART CHARGING ................................................................... 42
USE CASES IN USE CASE CLUSTER DEVICE 2 DEVICE ...................................................................... 43
SERVICES ADDRESSED BY USE CASES ............................................................................................ 60
TAB. 12
RESULTS OF INTEROPERABILITY DISCUSSION................................................................................ 65
© 2016
67
BIG IoT – Bridging the Interoperability Gap of the Internet of Things
Deliverable 2.2.a: Use Case Definition
Annex: Use Case and Service Definition
Version 1.3
Date: 29.06.2016
This project has received funding from the European Union’s Horizon 2020 research and
innovation programme under grant agreement No 688038.
ANNEX TO DELIVERABLE 2.2.A: USE CASE AND SERVICE DEFINITION
Responsible Person and Affiliation
D2.2.A ANNEX
VMZ Berlin:
Claudia Baumgartner, Christian Seidel,
Franka Heuer
Due Date / Delivery Date
29.06.2016
State
Final
Reviewers
Achille Zappa (NUIG)
Werner Schladofsky (Atos)
Version
1.3
Confidentiality
Public
© 2016
1
ANNEX TO DELIVERABLE 2.2.A: USE CASE AND SERVICE DEFINITION
D2.2.A ANNEX
Contents of the Annex
ABBREVIATIONS .................................................................................................................... 3
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS ................................................................... 4
1
DEVELOPMENT ECOSYSTEM USE CASES ........................................................................ 6
2
RESOURCE REGISTRATION, DISCOVERY AND ACCESS ECOSYSTEM USE CASES....................... 12
3
CHARGING AND BILLING ECOSYSTEM USE CASES........................................................... 16
4
CORE DEVELOPMENT ECOSYSTEM USE CASES .............................................................. 20
PART 2: PILOT USE CASE DESCRIPTIONS ........................................................................... 23
TEMPLATE FOR USE CASE DESCRIPTIONS .............................................................................. 26
1
SMART PARKING USE CASE CLUSTER .......................................................................... 27
2
SMART TRAFFIC MANAGEMENT USE CASE CLUSTER ...................................................... 49
3
PUBLIC TRANSPORT OPTIMIZATION USE CASE CLUSTER.................................................. 67
4
HEALTHY BIKE NAVIGATION USE CASE CLUSTER ........................................................... 76
5
SMART BIKE SHARING USE CASE CLUSTER ................................................................... 79
6
INCENTIVE BASED GREEN ROUTE PLANNING USE CASE CLUSTER ...................................... 84
7
MULTIMODAL ROUTE OPTIMIZATION USE CASE CLUSTER ............................................... 92
8
SMART CHARGING USE CASE CLUSTER ..................................................................... 102
9
DEVICE TO DEVICE COMMUNICATION USE CASE CLUSTER............................................. 109
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS ...................................................................112
TEMPLATE FOR SERVICE DESCRIPTIONS .............................................................................. 114
1
SMART PARKING RELATED SERVICES ........................................................................ 115
2
SMART TRAFFIC MANAGEMENT RELATED SERVICES..................................................... 120
3
PUBLIC TRANSPORT OPTIMIZATION RELATED SERVICE.................................................. 127
4
HEALTHY BIKE NAVIGATION RELATED SERVICES .......................................................... 129
5
SMART BIKE SHARING RELATED SERVICES ................................................................. 130
6
INCENTIVE BASED GREEN ROUTE PLANNING RELATED SERVICES ..................................... 131
7
MULTIMODAL ROUTE OPTIMIZATION RELATED SERVICES ............................................. 133
8
SMART CHARGING RELATED SERVICES ...................................................................... 137
© 2016
2
ANNEX TO DELIVERABLE 2.2.A: USE CASE AND SERVICE DEFINITION
D2.2.A ANNEX
Abbreviations
Abbreviation
API
BCN
BIG IoT
DOA
GPS
IFTTT
IoT
NG
OEM
PIE
SDK
SLA
UI
Meaning
Application Programming Interface
Barcelona (pilot)
Project title: Bridging the Interoperability Gap of the Internet of Things
Description of Action
Global Positioning System
https://ifttt.com/
Internet of Things
Northern Germany (pilot)
Original Equipment Manufacturer
Piedmont (pilot)
Software Development Kit
Service Level Agreement
User Interface
© 2016
3
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS
Part 1:
D2.2.A ANNEX
Ecosystem Use Case Descriptions
Part 1 of the Annex contains the detailed use case descriptions for BIG IoT Ecosystem use
cases. Structured by the use case clusters “Development”, “Resource Registrations, Discovery and Access”, “Charging and Billing” and “Core Development”, each use cases cluster contains use case scenarios (e.g. BEU-DEV-01 within the “Development” use case cluster).
The use case scenarios are shown with their atomic use cases in an overview (use case diagram) followed by user stories illustrating the scenarios. Stories can contain company names
(e.g. Bosch, VMZ etc.). Those names are for illustrative purposes only and do not refer to any
real action of those companies within the implementation phase of BIG IoT. Demonstration
and pilot-implementation is covered in Part 2.
Passages within the scenarios highlighted in italics refer to an atomic use case from the scenario use case overview.
© 2016
4
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS
D2.2.A ANNEX
Table of Contents Part 1: Ecosystem Use Cases
1
DEVELOPMENT ECOSYSTEM USE CASES ........................................................................ 6
1.1
BEU-DEV-1: BIG IOT DEVELOPER
STUDIES THE
BIG IOT
DOCUMENTATION, EXAMPLE
CODE AND DOWNLOADS AND USES THE OPEN SOURCE SDK........................................
1.2
BEU-DEV-2: BIG IOT SERVICE/PLATFORM DEVELOPER DEVELOPS A SERVICE OR EXTENDS
AN IOT PLATFORM TO REGISTER A RESOURCE OFFERING ON A MARKETPLACE .................
1.3
6
BEU-DEV-3:
BIG
APPLICATION/SERVICE
IOT
APPLICATION/SERVICE
DEVELOPER
DEVELOPS
8
AN
WHICH LEVERAGES A RESOURCE OFFERING PROVIDED ON A
MARKETPLACE................................................................................................ 9
1.4
BEU-DEV-4: BIG IOT SERVICE DEVELOPER
DEVELOPS A NEW
SERVICE
BASED ON
COMPOSITION OF EXISTING RESOURCE OFFERINGS ................................................. 10
2
RESOURCE REGISTRATION, DISCOVERY AND ACCESS ECOSYSTEM USE CASES....................... 12
2.1
BEU-RDA-1: BIG IOT SERVICE/PLATFORM
REGISTERS A RESOURCE OFFERING ON A
MARKETPLACE (–> PROVIDER SCENARIO) ........................................................... 12
2.2
BEU-RDA-2:
BIG
IOT
SERVICE/APPLICATION
USES/ACCESSES
A
RESOURCE
OFFERING PROVIDED VIA A MARKETPLACE (–> CONSUMER SCENARIO).......................
3
CHARGING AND BILLING ECOSYSTEM USE CASES........................................................... 16
3.1
BEU-CB-1: BIG IOT PLATFORM/SERVICE/APPLICATION
PERFORM
ACCOUNTING
FOR RESOURCES ACCESSED (PROVIDED/CONSUMED) ..............................................
3.2
3.3
16
BEU-CB-2: BIG IOT MARKETPLACE GIVES OFFERING PROVIDERS AND CONSUMERS ACCESS
TO CHARGING INFORMATION ............................................................................
18
BEU-CB-3: BIG IOT MARKETPLACE GIVES OFFERING PROVIDERS AND CONSUMERS ACCESS
TO BILLING RELATED FUNCTIONS/INFORMATION ....................................................
4
14
19
CORE DEVELOPMENT ECOSYSTEM USE CASES .............................................................. 20
4.1
BEU-COREDEV-1: BIG IOT CORE DEVELOPER DEVELOPS AND DOCUMENTS THE BIG IOT
CORE (API, MARKETPLACE...).......................................................................... 20
© 2016
5
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS
D2.2.A ANNEX
1
Development Ecosystem Use Cases
1.1
BEU-DEV-1: BIG IoT Developer studies the BIG IoT documentation, example code and downloads and uses the open
source SDK
Fig. 1
Use Case Overview in Ecosystem Use Case Scenario BEU-DEV-1
© 2016
6
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS
D2.2.A ANNEX
Story 1: BIG IoT Developer registers, authenticates and gets authorized
Before a Developer starts implementing a BIG IoT Application, Service or Platform, s/he
needs to be registered on a BIG IoT Marketplace. Once registered, the Developer can log-in
(authenticate) and is authorized as a Developer.
Story 2: BIG IoT Developer reads BIG IoT Development documentation and downloads the
SDK
BIG IoT Developer reads the BIG IoT development documentation, example code and downloads the Software Development Kit (SDK) in order to implement a BIG IoT enabled Platform
/ Service / Application for the BIG IoT Ecosystem.
Story 3: BIG IoT Developer gives feedback, and ask questions or report bugs
Via the Marketplace, i.e. BIG IoT Core Development Environment, the BIG IoT Developer is
able to give feedback about the BIG IoT Advanced Programming Interface (API), SDK, and
also ask questions about how to use it, how it works and/or report bugs/problems.
Story 4: BIG IoT Developer suggest new features
The Marketplace should also have an area where BIG IoT Developers can make suggestions
about new features, enhancements, etc.
© 2016
7
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS
1.2
Fig. 2
D2.2.A ANNEX
BEU-DEV-2: BIG IoT Service/Platform Developer develops a
Service or extends an IoT Platform to register a resource offering on a Marketplace
Use Case Overview in Ecosystem Use Case Scenario BEU-DEV-2
Story 1: VMZ wants to offer information (e.g. parking data) or access to functions via its
IoT Platform on the BIG IoT Marketplace
A developer of VMZ's1 IoT Platform will authenticate on the IoT Marketplace (on behalf of
VMZ). If the BIG IoT API SDK is not yet known and has not yet been downloaded, the developer will first read the documentation and then download the SDK for the respective development environment.
In a next step, the developer defines the semantic description of the information or function
(= resource offering) that VMZ wants to offer on the Marketplace. For this, the developer
can use a User Interface guided semantic description tool, which will allow the developer to
automatically define the semantic description. For example, VMZ wants to offer parking information for Berlin. The UI guided semantic description tool will allow the developer to define for example, the Domain (Smart City), the City (Berlin), the Area (GPS/Street of parking
lot), the Type of parking lot (e.g. garage, street parking, outdoor parking lot), etc. Once finished, the tool will automatically generate the semantic description in the language of choice
by the developer. The developer can use the generated semantic description in the BIG IoT
API calls to the Marketplace.
1
Company names are mentioned here solely for illustration of the interaction with the BIG IoT ecosystem. They
do not reference to real implementation plans or pilot demonstration (cf. page 4).
© 2016
8
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS
D2.2.A ANNEX
For the extension of the IoT Platform with the BIG IoT API, the developer can also use a User
Interface guided code generation tool for the BIG IoT API calls. Here, the developer can for
example define the target programming language, the type of calls it want to make - e.g.
registration of information or functions, the cost of access, the SLA offered, etc. The tool will
at the end auto-generate the required source code in the target language to make the relevant BIG IoT API calls from the IoT Platform. The developer can either store the generated
code in a program file or copy paste the results into his development environment.
Finally, once the IoT Platform has been extended to support the BIG IoT API, the developer
can also leverage test routines provided by the BIG IoT API SDK in order to test/check the API
calls.
1.3
Fig. 3
BEU-DEV-3: BIG IoT Application/Service Developer develops
an Application/Service which leverages a resource offering
provided on a Marketplace
Use Case Overview in Ecosystem Use Case Scenario BEU-DEV-3
Story 1: Bosch wants to offer a Green Routing Application for Berlin and wants to offer
traffic flow information provided by VMZ via the BIG IoT Marketplace
A developer of Bosch's 2 Smart Parking Application will authenticate on the IoT Marketplace
(on behalf of Bosch). If the BIG IoT API SDK is not yet known and has not yet been downloaded, the developer will first read the documentation and then download the SDK for the
respective development environment.
2
Company names are mentioned here solely for illustration of the interaction with the BIG IoT ecosystem. They
do not reference to real implementation plans or pilot demonstration (cf. page 4).
© 2016
9
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS
D2.2.A ANNEX
In a next step, the developer will browse the Marketplace to see what type of resources, i.e.
offerings, are available. Via a nice User Interface, the developer will be able to explore the
offerings based on their semantic descriptions. The developer may also have a chance to
preview some sample data. Once the developer has selected the basic type of data (e.g.
based on a semantic model), the User Interface will guide the developer to define the semantic query for the type of resources s/he desires for its Application or Service.
For example, Bosch is looking for available parking lot information in Berlin. The UI guided
semantic description tool will allow the developer to define for example, if the Application is
looking for information or functions, the Domain (Smart City), the Area (GPS/Streets), the
Type parking lot (e.g. garage, street parking, outdoor), etc. Once finished, the tool will automatically generate the semantic query ready to use by the developer. The developer can use
the generated semantic query in the BIG IoT API calls to the Marketplace.
For the development of the Smart Parking Application, the developer can also use a User
Interface guided code generation tool for the BIG IoT API calls. Here, the developer can for
example define the target programming language, the type of calls it want to make - e.g.
query of information, the max. cost of the information, the expected SLA, etc. The tool will
at the end auto-generate the required source code in the target language to make the relevant BIG IoT API calls from the Smart Parking Application. The developer can either store the
generated code in a program file or copy paste the results into his development environment.
Finally, once the Smart Parking Application that accesses the BIG IoT API has been developed, the developer can also leverage test routines provided by the BIG IoT API SDK in order
to test/check the API calls.
1.4
BEU-DEV-4: BIG IoT Service Developer develops a new Service
based on composition of existing resource offerings
This use case slightly differentiates from BEU-DEV-3. It also creates a new Service, however,
focuses on composition of multiple (at least 2) available offerings on the Marketplace. Those
offerings are discovered via the Marketplace. The composition of offerings is formally described (see figure below for a simple example). This description is associated with the new
Service and helps to enable adjustment of the composition if needed (e.g., exchange of one
composition member if a cheaper one is found).
© 2016
10
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS
Fig. 4
D2.2.A ANNEX
Use Case Overview in Ecosystem Use Case Scenario BEU-DEV-4
Story 1
A developer of VMZ's 3 platform will authenticate on the IoT Marketplace (on behalf of VMZ).
In a next step, the developer wants to create a new service by leveraging (composing) existing offerings on the Marketplace (e.g. as in IFTTT.com recipes which create value-added services based on existing services).
The developer browses the Marketplace to see the available offerings. For this a semantic
query will be generated and the developer can get the semantic description of available offerings.
The developer uses the discovered offerings to create a new composed service, for example
route to free bike. For this, the developer first decides the order in which offerings should to
be accessed.
The composition step (compose discovered offerings) is guided by a User Interface (UI) on
the Marketplace, which assists the developer to compose the new service (e.g. similar to
IFTTT.com). Then s/he defines a new semantic description for the composed service which
3
Company names are mentioned here solely for illustration of the interaction with the BIG IoT ecosystem. They
do not reference to real implementation plans or pilot demonstration (cf. page 4).
© 2016
11
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS
D2.2.A ANNEX
can be used in the BIG IoT API calls to the Marketplace. The semantic description may contain metadata such as the composed offerings, the order in which the composed offerings
should be accessed, how to access the resources, the price of the value-added service, location, quality, observation area, availability of the service, etc.
2
Resource Registration, Discovery and Access Ecosystem Use Cases
2.1
BEU-RDA-1: BIG IoT Service/Platform registers a resource offering on a Marketplace (–> Provider Scenario)
Fig. 5
Use Case Overview in Ecosystem Use Case Scenario BEU-RDA-1
© 2016
12
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS
D2.2.A ANNEX
Story 1: VMZ offers Traffic Flow Information from its BIG IoT enabled Platform on the BIG
IoT Marketplace
VMZ4 is a registered BIG IoT Platform Provider for the TIC Platform. The BIG IoT enabled platform collects traffic flow data around the city of Berlin and offers these on the BIG IoT Marketplace. The Platform authenticates itself (via the BIG IoT API) to the BIG IoT Marketplace
and registers the offered traffic flow information (= offering) on the Marketplace by providing a semantic description of the information: data types, context data (location and time),
costs, SLA, etc.
The BIG IoT Platform also controls access to ensure that only authorized BIG IoT Applications
or Services (consumers) are allowed to get access to the offered information.
Story 2: VMZ offers an Emergency Traffic Management Service on the BIG IoT Marketplace
VMZ5 is a registered BIG IoT Service Provider that offers an Emergency Traffic Management
Service that allows the Emergency Services (i.e. police, fire brigade and ambulance) to prioritize the traffic flow along specific routes in case of an emergency event. The BIG IoT Service authenticates itself (via the BIG IoT API) to the BIG IoT Marketplace and registers the
"emergency traffic control" function (=offering) on the Marketplace, based on a semantic
description of the functionality.
The BIG IoT Service also controls access to ensure that only authorized BIG IoT Applications
or Services are allowed to get access to the offered functionality.
4
Company names are mentioned here solely for illustration of the interaction with the BIG IoT ecosystem. They
do not reference to real implementation plans or pilot demonstration (cf. page 4).
5
As above.
© 2016
13
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS
2.2
Fig. 6
D2.2.A ANNEX
BEU-RDA-2: BIG IoT Service/Application uses/accesses a resource offering provided via a Marketplace (–> Consumer
Scenario)
Use Case Overview in Ecosystem Use Case Scenario BEU-RDA-2
Story 1: BOSCH offers Green Routing Service based on already available information resources offered on a BIG IoT Marketplace
Bosch6 is a BIG IoT Service Provider and offers a Green Routing Service for Berlin based on
already available information resources offered on a BIG IoT Marketplace. For this, Bosch
is registered as a Service Provider on the BIG IoT Marketplace. The Green Routing Service
first authenticates itself on the Marketplace and then discovers available and relevant traffic
and pollution information (= offerings) for Berlin via the BIG IoT Marketplace. The service discovers, for example, the traffic information provided by VMZ's Traffic Platform in
6
Company names are mentioned here solely for illustration of the interaction with the BIG IoT ecosystem. They
do not reference to real implementation plans or pilot demonstration (cf. page 4).
© 2016
14
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS
D2.2.A ANNEX
Berlin, based on the semantic descriptions. The service accesses the VMZ offered information and combines them with pollution information around Berlin from another provider in order to provide the Green Routing Service.
Story 2: Berlin's Emergency Service Center uses a BIG IoT Application that allows them to
control traffic flows during emergency events
Berlin's Emergency Service Center7 contracted an SME to develop a BIG IoT Application to
control traffic flows during emergency events. Berlin's Emergency Service Center
is registered as a BIG IoT User on the Marketplace. The Emergency Traffic Application
first authenticates itself on the Marketplace and then discovers available traffic management
functions (= offerings) for Berlin. The application discovers, for example, VMZ's Traffic Management Service (see above), based on the semantic descriptions. The application accesses the VMZ offered traffic management functions to control the traffic flows in
case of an emergency event.
7
Company names are mentioned here solely for illustration of the interaction with the BIG IoT ecosystem. They
do not reference to real implementation plans or pilot demonstration (cf. page 4).
© 2016
15
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS
D2.2.A ANNEX
3
Charging and Billing Ecosystem Use Cases
3.1
BEU-CB-1: BIG IoT Platform/Service/Application perform accounting for resources accessed (provided/consumed)
Fig. 7
Use Case Overview in Ecosystem Use Case Scenario BEU-CB-1
© 2016
16
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS
D2.2.A ANNEX
Story 1: BIG IoT Marketplace charges Bosch Smart Routing Application for accessing resources provided by a VMZ BIG IoT Service
VMZ8 is a BIG IoT Service Provider that offers access to traffic flow data in the City of Berlin
via the BIG IoT Marketplace. Bosch offers a Smart Routing Application to its customers. The
Smart Routing Application discovers the Traffic Flow Service by searching available traffic
flow data offerings on the Marketplace. Before accessing information provided by the VMZ
Traffic Flow Service, the Routing Applications contacts the BIG IoT Marketplace (via the BIG
IoT API), which provides a valid charging token to the application if the BIG IoT User (e.g.
OEM) of the Smart Routing Application has a contract or a pre-paid service.
Whenever the Smart Routing Application accesses the data provided by the Traffic Flow Service, the service will first check if the consumer is authorized and has a valid charging token.
The Traffic Flow Service performs accounting (by collecting charging records for access information) and sends the accounting data (e.g. how many queries, how much information,
etc.) to the BIG IoT Marketplace. VMZ's Service will send these accounting data on a regular
basis (e.g. every 5 minutes or after every 1000 queries) or when a session is terminated.
Optionally, the Smart Routing Application may also collect and send usage records (e.g. how
many queries, how much information, etc.) to the Marketplace, in order to identify inconsistencies early and indicate a warning.
The BIG IoT Marketplace collects the accounting data from the Traffic Flow Service and optionally also collects the usage data from the Smart Routing Application. In case of inconsistencies, it can inform the application or BIG IoT User of the application about the issue.
Upon terminating a session or on a regular basis, the Marketplace generates the invoice
based on the collected charging information.
8
Company names are mentioned here solely for illustration of the interaction with the BIG IoT ecosystem. They
do not reference to real implementation plans or pilot demonstration (cf. page 4).
© 2016
17
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS
3.2
Fig. 8
D2.2.A ANNEX
BEU-CB-2: BIG IoT Marketplace gives offering providers and
consumers access to charging information
Use Case Overview in Ecosystem Use Case Scenario BEU-CB-2
Story 1: VMZ, as a BIG IoT Platform and Service Provider, checks the charging related information of their BIG IoT Platform and Service on the Marketplace
VMZ9, as BIG IoT Platform and Service Provider, authenticates itself on the BIG IoT Marketplace via the web portal. The Marketplace offers VMZ a view to the up-to-date charging records for all of its platforms and services offered via this Marketplace. This allows VMZ to
check the usage and revenue generated by its Marketplace offers.
Story 2: Berlin City Council, as a BIG IoT Application User, checks the charging related information of the application on the Marketplace
The Berlin City Council10, who runs a BIG IoT Application to check the traffic situation around
the city, wants to check the consumption and charging information of its application on the
Marketplace. For this, the responsible employee authenticates itself via the Web Portal of
the Marketplace (on behalf of the Berlin City Council) and then views the consumption and
charging information of the used application. The employee can also set a charging limit or
configure the Marketplace to send a warning message once a certain limit is reached.
9
Company names are mentioned here solely for illustration of the interaction with the BIG IoT ecosystem. They
do not reference to real implementation plans or pilot demonstration (cf. page 4).
10
As above.
© 2016
18
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS
3.3
Fig. 9
D2.2.A ANNEX
BEU-CB-3: BIG IoT Marketplace gives offering providers and
consumers access to billing related functions/information
Use Case Overview in Ecosystem Use Case Scenario BEU-CB-3
Story 1: VMZ defines the payment model for the usage of its value-added service
VMZ11, a BIG IoT Service Provider as described in the earlier use case scenarios, wants to
define a billing model for the usage of its value-added Service. This can be defined in the BIG
IoT Marketplace. First, the responsible employee of VMZ will authenticate himself (on behalf
of VMZ) with the Marketplace, which in turn will authorize the user. He will then select and
define the supported contract models - prepaid and/or subscription-based - to cater for the
different groups of consumers, and define the invoice template and pricing models for the
billing. He will also be able to define the invoice schedule, etc. Besides the default pricing
model, Service Providers can define special pricing models, for special customers (groups).
Consumers of the Marketplace (i.e. BIG IoT Users of an Application or Service Providers) will
also authenticate themselves and chose the desired payment model prior to discovering and
accessing any service. If prepaid is chosen, the consumer would make a payment online in
order to get credits. If a subscription based contract is chosen, the consumer would be
charged by the provider according to the defined invoice schedule and pricing model, till the
termination or end of contract. The invoices are created automatically from a defined template. Providers and Consumers are able to view the invoice and history.
11
Company names are mentioned here solely for illustration of the interaction with the BIG IoT ecosystem.
They do not reference to real implementation plans or pilot demonstration (cf. page 4).
© 2016
19
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS
D2.2.A ANNEX
4
Core Development Ecosystem Use Cases
4.1
BEU-COREDEV-1: BIG IoT Core Developer develops and documents the BIG IoT Core (API, Marketplace...)
Fig. 10
Use Case Overview in Ecosystem Use Case Scenario BEU-COREDEV-1
© 2016
20
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS
D2.2.A ANNEX
Story 1: Core Developer registers, authenticates and gets authorized
Before a Core Developer can contribute to the BIG IoT Ecosystem development, s/he needs
to be registered on the BIG IoT Core Development Environment (e.g. GitLab). Once registered, the developer can log-in (authenticate) and is authorized according to his role.
Story 2: Core Developer clones GIT repository
In order to contribute to the core development of the BIG IoT Ecosystem, the Core Developer needs to clone the respective GIT repository.
Story 3: Core Developer creates issue
Development of BIG IoT should be driven and controlled by issues.
Core Developers can create issues (with detailed description) for new features or when they
find a bug.
(Details about the BIG IoT development process have to be clarified)
Story 4: Core Developer develops changes or new core function, and commits source code
Once a Core Developer has done his code changes, s/he will commit the source code of the
changed code/function (API or core service) to the BIG IoT Core Development Repository.
After the source code has been committed, the Development Repository is triggered to build
the changed service and runs all the tests. After the successful build and tests, a Docker image is created and pushed to the BIG IoT Core Software Repository. This image has to be deployed manually.
© 2016
21
PART 1: ECOSYSTEM USE CASE DESCRIPTIONS
D2.2.A ANNEX
Story 5: Core Developer deploys and tests the new/changed core function
After a new version of a service binary (in the form of a Docker image) is available in the
Software Repository, the Core Developer can deploy this binary code/function to the Execution Environment into one of several stages. These stages might be “dev” (for developer
tests), “test” (for system tests), “load” (for load tests) or “prod” (for productive operation).
After testing the new service in one stage it might be promoted to the next stage until it
ends in the prod stage and is available for productive use.
(Details about the different stages are still to be clarified.)
Story 6: Core Developer creates merge request
Once the tests have been successful, the Core Developer will create a merge request in the
Core Development Repository.
The merge requests will be reviewed and checked by an authorized Core Developer, who will
either accept or reject the merge request.
Story 7: Core Developer updates or write documentation of new/updated core function/service
To support clients of the BIG IoT Ecosystem, the Core Developer writes down or updates all
the necessary documentation for the new/changed core function (API or core service) in the
documentation part of the Development Repository. This documentation can then be used
by another developer that wants to use this functionality.
Story 8: Core Developer closes issue
When a feature has been implemented or a bug has been fixed the according issue is closed.
© 2016
22
PART 2: PILOT USE CASE DESCRIPTIONS
Part 2:
D2.2.A ANNEX
Pilot Use Case Descriptions
Part 2 of the annex contains the detailed use case descriptions. Structured by use case cluster and pilots, each use case is described using the template table shown on page 26. The
following table of contents shows the use cases structured by use case cluster and pilot site.
Table of Contents Part 2: Pilot Use Cases
1
SMART PARKING USE CASE CLUSTER .......................................................................... 27
1.1
NORTHERN GERMANY PILOT ............................................................................ 27
[SP-NG-01] / FIND FREE PARKING SPOT, SMARTPHONE APP BASED ................................. 28
[SP-NG-02] / FIND FREE PARKING SPOT, WITH CAR INTEGRATION ................................... 29
[SP-NG-03] / PREDICT PARKING SPACE AVAILABILITY....................................................... 30
[SP-NG-04] / RESERVE PARKING SPOT ............................................................................. 31
[SP-NG-05] / ROUTE TO PARKING SPOT........................................................................... 32
[SP-NG-06] / PAY FOR STAY ............................................................................................. 33
[SP-NG-11] / MONITOR PARKING-SPOTS FROM DESK ...................................................... 34
[SP-NG-12] / MONITOR PARKING-SPOTS ON-STREET ....................................................... 35
1.2
BARCELONA PILOT ......................................................................................... 36
[SP-BCN-01] / FIND FREE PARKING SPOT ......................................................................... 37
[SP-BCN-02] / FIND PROBABLE PARKING AREA ................................................................ 38
[SP-BCN-03] / RESERVE PARKING SPOT ........................................................................... 39
[SP-BCN-04] / ROUTE TO PARKING SPOT ......................................................................... 40
[SP-BCN-05] / CHECK-IN .................................................................................................. 41
[SP-BCN-06] / CHECK-OUT............................................................................................... 42
[SP-BCN-07] / PAY FOR STAY ........................................................................................... 43
1.3
PIEDMONT PILOT .......................................................................................... 44
[SP-PIE-01] / FIND FREE PARKING SPOT, SMARTPHONE APP BASED ................................. 45
[SP-PIE-04] / ROUTE TO PARKING SPOT........................................................................... 46
[SP-PIE-12] / MONITOR PARKING SPOTS, BROWSER BASED ............................................. 47
[SP-PIE-20] / MONITOR PARKING SPOTS, APP BASED ...................................................... 48
2
SMART TRAFFIC MANAGEMENT USE CASE CLUSTER ...................................................... 49
2.1
BARCELONA PILOT ......................................................................................... 49
[STM-BCN-01] / GET TRAFFIC INFORMATION .................................................................. 50
[STM-BCN-02] / MONITOR TRAFFIC ALARMS................................................................... 51
[STM-BCN-03] / GET TRAVEL TIMES BETWEEN TWO POINTS ........................................... 52
[STM-BCN-04] / MONITOR ENVIRONMENT ALARMS ....................................................... 53
[STM-BCN-05] / SET ENVIRONMENT RECOMMENDATIONS ............................................. 54
[STM-BCN-06] / GET ENVIRONMENT RECOMMENDATIONS............................................. 55
© 2016
23
PART 2: PILOT USE CASE DESCRIPTIONS
2.2
D2.2.A ANNEX
PIEDMONT PILOT .......................................................................................... 56
[STM-PIE-01] / GET TRAFFIC INFORMATION, VIA BROWSER ............................................ 57
[STM-PIE-02] / MONITOR TRAFFIC ALARMS .................................................................... 58
[STM-PIE-03] / GET AIR QUALITY CONDITIONS, VIA BROWSER......................................... 59
[STM-PIE-04] / MONITOR ENVIRONMENT ALARMS, VIA BROWSER.................................. 60
[STM-PIE-05] / MONITOR NOISE ..................................................................................... 61
[STM-PIE-06] / SMART WASTE MANAGEMENT WITHDRAWAL ......................................... 62
[STM-PIE-07] / O/D MATRICES GENERATION ................................................................... 63
[STM-PIE-08] / TRANSPORTATION MODES ...................................................................... 64
[STM-PIE-09] / TRANSPORT MODES ROUTES ................................................................... 65
2.3
NORTHERN GERMANY PILOT ............................................................................ 66
[STM-NG-01] / SMART NET BALANCING .......................................................................... 66
3
PUBLIC TRANSPORT OPTIMIZATION USE CASE CLUSTER.................................................. 67
3.1
NORTHERN GERMANY PILOT ............................................................................ 67
[PTO-NG-01] / OPTIMIZE PUBLIC TRANSPORT RESOURCES .............................................. 68
[PTO-NG-02] / OPTIMIZE PUBLIC TRANSPORT SELECTION/GUIDANCE.............................. 69
[PTO-NG-03] / OPTIMIZE END-USER EXPERIENCE AT PUBLIC TRANSPORT STOP ............... 70
[PTO-NG-04] / OPTIMIZE END-USER EXPERIENCE WHEN TAKING PUBLIC TRANSPORT ..... 71
[PTO-NG-06] / LIVE BUS TRACKING ................................................................................. 72
[PTO-NG-07] / PEOPLE DENSITY ESTIMATION BASED ON SMART BUSES .......................... 73
[PTO-NG-08] / IDENTIFICATION OF PEOPLE FLOW ALONG BUS LINE ................................ 74
[PTO-NG-09] / CREATING A MODEL FOR PREDICTION OF BUS UTILIZATION ..................... 75
4
HEALTHY BIKE NAVIGATION USE CASE CLUSTER ........................................................... 76
4.1
PIEDMONT PILOT .......................................................................................... 76
[HBN-PIE-01] / FIND HEALTHIER ROUTE .......................................................................... 77
[HBN-PIE-02] / NAVIGATE TO DESTINATION THROUGH HEALTHIER ROUTE ...................... 78
5
SMART BIKE SHARING USE CASE CLUSTER ................................................................... 79
5.1
PIEDMONT PILOT .......................................................................................... 79
[SBS-PIE-01] / DOCKS AND BIKES AVAILABILITY ............................................................... 80
[SBS-PIE-02] / ESTIMATE BIKE AVAILABILITY .................................................................... 81
[SBS-PIE-03] / ESTIMATE OPEN DOCK AVAILABILITY ........................................................ 82
[SBS-PIE-04] / LOCATE BIKE ............................................................................................. 83
© 2016
24
PART 2: PILOT USE CASE DESCRIPTIONS
6
D2.2.A ANNEX
INCENTIVE BASED GREEN ROUTE PLANNING USE CASE CLUSTER ...................................... 84
6.1
BARCELONA PILOT ......................................................................................... 84
[GRP-BCN-01] / FIND GREEN ROUTES .............................................................................. 85
[GRP-BCN-02] / GET ALTERNATIVE TRANSPORT MODES .................................................. 86
[GRP-BCN-03] / FOLLOW GREEN RECOMMENDATIONS ................................................... 87
6.2
PIEDMONT PILOT .......................................................................................... 88
[GRP-PIE-01] / FIND GREEN ROUTES................................................................................ 89
[GRP-PIE-02] / GET ALTERNATIVE TRANSPORT MODES .................................................... 90
[GRP-PIE-03] / FOLLOW GREEN RECOMMENDATIONS ..................................................... 91
7
MULTIMODAL ROUTE OPTIMIZATION USE CASE CLUSTER ............................................... 92
7.1
NORTHERN GERMANY PILOT ............................................................................ 92
[MRO-NG-01] / INITIAL INTERMODAL ROUTING START TO DESTINATION ........................ 93
[MRO-NG-02] / SAVE MULTIMODAL ROUTE .................................................................... 94
[MRO-NG-03] / MONITOR STREET TRAFFIC SITUATION ................................................... 95
[MRO-NG-04] / MONITOR RAIL SITUATION ..................................................................... 96
[MRO-NG-05] / DETOUR ................................................................................................. 97
[MRO-NG-06] / FIND ALTERNATIVE VEHICLE ................................................................... 98
[MRO-NG-07] / RESERVE ALTERNATIVE VEHICLE ............................................................. 99
[MRO-NG-08] / CHECK STATE OF RELATIONS................................................................. 100
[MRO-NG-09] / INFORM COMMUTER ABOUT DEVIATION ............................................. 101
8
SMART CHARGING USE CASE CLUSTER ..................................................................... 102
8.1
NORTHERN GERMANY PILOT ...........................................................................102
[SC-NG-01] / FIND FREE CHARGING STATION ................................................................ 103
[SC-NG-02] / RESERVE CHARGING INFRASTRUCTURE..................................................... 104
[SC-NG-03] / ROUTE TO CHARGING INFRASTRUCTURE .................................................. 105
[SC-NG-04] / PAY FOR CHARGE ..................................................................................... 106
[SC-NG-11] / OBSERVE CHARGING INFRASTRUCTURE FROM DESK................................. 107
[SC-NG-12] / OBSERVE INFRASTRUCTURE ON-STREET ................................................... 108
9
DEVICE TO DEVICE COMMUNICATION USE CASE CLUSTER............................................. 109
9.1
BARCELONA PILOT ........................................................................................109
[D2D-BCN-01] / PEDESTRIAN - TRAFFIC LIGHT INTERACTIONS ....................................... 110
[D2D-BCN-02] / CYCLER- TRAFFIC LIGHT INTERACTIONS ................................................ 111
© 2016
25
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
Template for Use Case Descriptions
ID
unique identifier indicating use case cluster, pilot and title
Description
short description of the use case
Goal
goal of the use case
Actor
the system or natural person in direct interaction with the system
Data Provider
the company or system providing smart object data to the system
S/A-Provider
the company providing the services (S) or applications (A) needed to run the
use case
Smart Objects
actual smart objects involved in this use case
Platforms
platforms involved in this use case
Stakeholders
main external stakeholders affected by this use case
Benefits
benefits for stakeholders
Stories
use case stories
Annotations
Additional information
Tab. 1
Use Case Description Template
© 2016
26
PART 2: PILOT USE CASE DESCRIPTIONS
1
D2.2.A ANNEX
Smart Parking Use Case Cluster
The use case cluster Smart Parking is addressed in the Northern Germany Pilot, the Barcelona Pilot and the Piedmont Pilot.
1.1
Northern Germany Pilot
The following eight use cases are addressed in the Northern Germany Pilot within the Smart
Parking use case cluster.
Fig. 11
Smart Parking Use Cases in Northern Germany Pilot
© 2016
27
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SP-NG-01] / Find free parking spot, smartphone app based
Description
Recommendation for parking spots based on location, availability and distance.
This involves new parking spot observing smart objects.
Goal
Make data of smart objects “parking detectors” available via BIG IoT API at TIC
Platform and use it in app via BIG IoT API.
Actor
traffic participant
Data Provider
Siemens
S/A-Provider
Siemens / VMZ Berlin
Smart Objects
Parking spot detectors [online-data]
Platforms
TIC-Platform
Stakeholders
City council
City inhabitants
Benefits
Reduce search time for parking spots [traffic participant]
Reduce cost while searching for parking spots [traffic participant]
Reduce emissions through parking spot search times
Reduce congestion
Increase user comfort
Annotations
Stories
© 2016
28
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SP-NG-02] / Find free parking spot, with car integration
Description
Recommendation for parking spots when reaching the destination area based
on destination, availability, prices and user preferences. The recommendation
should be displayed inside the car on the HU.
Goal
Demonstrate integration of various information sources into single Smart Parking App that runs in the car. The App will access the information sources via the
BIG-IoT API.
The goal is to demonstrate the same Smart Parking App in the NG Pilot (Bosch
Car with mySPIN) as well as the Barcelona Pilot (SEAT Car with MirrorLink).
Actor
Traffic Participant
Data Provider
NG Pilot: Siemens / VMZ Berlin / WAG(?); Barcelona Pilot: WorldSensing, City
Council
S/A-Provider
Bosch as Application Provider
Smart Objects
Parking spot detectors [online-data]
Cars (Smartphones)
Platforms
APM – Platform [Parking-Data Provider]
TIC-Platform
Bosch BEZIRK Platform
Stakeholders
City council
City inhabitant
Benefits
Reduce search time for parking spots [traffic participant]
Reduce cost while searching for parking spots [traffic participant]
Reduce emissions through parking spot search times
Reduce congestion
Increase user comfort
Stories
© 2016
29
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SP-NG-03] / Predict parking space availability
Description
Get estimate of availability of parking space within a time span, based on number of users in area, or moving towards area.
Based on information about people density, a probability can be given to the
user relating to the chance of the parking space being available when the user
reaches it.
Goal
To make the decision of where to go to find an available parking space smarter.
Actor
Traffic Participant
Data Provider
WAG - information about number of people in the area of the parking spot
S/A-Provider
AAU / WAG
Smart Objects
Smart devices connected (and possibly not connected) to the Wolfsburg WLAN
Platforms
WLAN infrastructure Wolfsburg
Stakeholders
City inhabitants
Benefits
Reduce search time for parking spots (less time wasted driving to parking spaces that are taken when finally reached) [traffic participant]
Reduce emissions through parking spot search times
Reduce congestion
Annotations
Stories
© 2016
30
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SP-NG-04] / Reserve Parking Spot
Description
Make a Reservation of a (private) Parking Spot for a specific period of time.
Goal
Showcase seamless mobility by connecting functionalities of different providers
via BIG IoT API
Actor
traffic participant
Data Provider
Siemens (Parking-Platform)
S/A-Provider
VMZ
Smart Objects
parking sensors
parking spot reservation indication display
Platforms
VMZ TIC /
some Parking Clearance Entity
Stakeholders
traffic participant
Benefits
traffic participant has his parking spot for sure
Annotations
UC for later stage or open call, regulatory and technical implementation not yet
sure
Stories
© 2016
31
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SP-NG-05] / Route to Parking Spot
Description
Allow a user (traffic participant) to be routed directly to a parking spot or to his
final destination via a parking spot taking actual traffic condition into account.
Goal
Showcase for seamless mobility by integrating different services into one app
via BIG IoT API.
Actor
Traffic Participant
Data Provider
VMZ
S/A-Provider
VMZ
Smart Objects
Traffic Detectors / Floating Car Data
Platforms
VMZ TIC
Stakeholders
city inhabitants
Benefits
traffic participant: less searching time
city inhabitants: less congestion / park searching traffic
Annotations
Stories
© 2016
32
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SP-NG-06] / Pay for Stay
Description
The traffic participant will be allowed to pay his parking fees without using an
on-street ticketing-machine. He pays via his smartphone.
Goal
Showcase the seamless integration of all parking-relevant processes within the
use case cluster.
Actor
Traffic participant dropping his car on a commercial parking lot or within a parking zone.
Data Provider
Smartphone (App) --> position
S/A-Provider
Some external payment provider
Smart Objects
Smartphone (communicating the actual location of the user / car to the service
provider that clears the payment)
Platforms
VMZ TIC, external parking clearance provider
Stakeholders
Traffic Participant
Benefits
Traffic Participant does not have to look for a parking ticket vending machine
but can pay directly via his smartphone.
Annotations
For later stage or Open Call
Stories
© 2016
33
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SP-NG-11] / Monitor Parking-Spots from Desk
Description
Via an online-GUI, a parking enforcement officer shall be given high level overviews of parking violations in his area to improve efficiency and impact of parking enforcement.
Goal
Showcase of seamless usage of data / services via BIG IoT API.
Actor
Regulatory agency employee / supervisor.
Data Provider
Siemens (APM)
S/A-Provider
VMZ
Smart Objects
APM Parking Sensor
Platforms
VMZ TIC
Stakeholders
Traffic Participants
Benefits
A regulatory agency employee can from his desk monitor the on street situation
in his whole enforcement-area and decide where it makes sense to go for an
enforcement walk.
A regulatory agency supervisor can see historical statistics to monitor the efficiency and impact of the enforcement efforts.
Annotations
For later stage or Open Call.
Stories
© 2016
34
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SP-NG-12] / Monitor Parking-Spots On-Street
Description
Via a mobile device App (e.g. for a tablet-pc), a parking enforcement officer
shall be given high low level information of parking situation, violations and
basics.
Goal
Showcase of seamless usage of data / services via BIG IoT API.
Actor
Regulatory agency employee
Data Provider
Siemens
S/A-Provider
VMZ
Smart Objects
Parking Sensor Data
Restriction Recognition Sensor
Platforms
VMZ TIC-Platform
Stakeholders
Traffic Participant
Benefits
A regulatory agency employee can with a mobile device monitor the on street
situation and decide where it makes sense to further go on his walk. The device
supports his walk with further information.
Annotations
For later stage or Open Call.
Stories
© 2016
35
PART 2: PILOT USE CASE DESCRIPTIONS
1.2
D2.2.A ANNEX
Barcelona Pilot
The following seven use cases are addressed in the Barcelona Pilot within the Smart Parking
use case cluster.
Fig. 12
Smart Parking Use Cases in Barcelona Pilot
© 2016
36
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SP-BCN-01] / Find free parking spot
Description
Recommendation for parking spots based on location, availability, distance and
parking prices. This involves new parking spot observing smart objects.
Goal
To reduce the volume of agitated traffic by providing efficient ways to find
available parking spots, through the use of real time parking availability data
from the “parking detector” smart objects.
Actor
Traffic Participant
Data Provider
WorldSensing + potential new stakeholders
S/A-Provider
WorldSensing / SEAT app
Smart Objects
Parking spot detectors [online-data]
Smart phone connected to SEAT Car via MirrorLink
Platforms
WorldSensing
Open IoT
Stakeholders
City council
City inhabitants
Benefits
Reduce search time for parking spots [traffic participant]
Reduce cost while searching for parking spots [traffic participant]
Reduce emissions through parking spot search times
Reduce congestion
Annotations
It uses a BIG IoT Parking Monitoring Service that will provide real-time information on parking lots availability (individually or per zone)
Stories
© 2016
37
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SP-BCN-02] / Find Probable Parking Area
Description
Get estimate of availability of parking space within a time span based on a predictive service.
Goal
To make the decision of where to go to find an available parking spot based on
predictive information.
Actor
Traffic Participant
Data Provider
WorldSensing + potential new stakeholders
S/A-Provider
WorldSensing
Smart Objects
Parking Spot Detectors (on-line and historical information elaborated by specific service)
Smart phone connected to SEAT Car via MirrorLink
Platforms
WorldSensing
Open IoT
Stakeholders
Barcelona City Council and potential new ones (B:SM, SABA)
Benefits
Reduce search time for parking spots (less time wasted driving to parking spaces that are taken when finally reached) [traffic participant]
Reduce emissions through parking spot search times
Reduce congestion
Annotations
It uses a BIG IoT or an external Parking Predictive Service that returns shorttime predictive information based on historical information (may be also other
sources)
Stories
© 2016
38
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SP-BCN-03] / Reserve Parking Spot
Description
Make a Reservation of a (private) Parking Spot for a specific period of time.
Goal
To avoid search time for parking spots because the traffic participant will have
available his/her parking spot for sure. Consequently, the intense traffic due to
searching for parking space will be reduced.
Actor
Traffic Participant
Data Provider
External Data Provider
S/A-Provider
Some external Parking Company
Smart Objects
Parking sensors
Parking spot reservation indication display
Platforms
Some external Parking Company
Stakeholders
Traffic Participant
Benefits
Traffic participant has his parking spot for sure
Stories
© 2016
39
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SP-BCN-04] / Route to Parking Spot
Description
Allow a user (Traffic Participant) to be routed directly to a parking spot or to his
final destination via a parking spot (optionally taking actual traffic condition
into account).
Goal
To help the user in the process of driving to a parking spot.
Actor
Traffic Participant
Data Provider
WorldSensing
S/A-Provider
External Routing Service / SEAT App
Smart Objects
Parking Spot Detectors (on-line)
Traffic Detectors (optionally if routing service requires it)
Smart phone connected to SEAT Car via MirrorLink
SEAT Car navigator (optionally)
Platforms
WorldSensing
Open IoT
Stakeholders
city inhabitants
Benefits
traffic participant: less searching time
city inhabitants: less congestion / park searching traffic
Stories
© 2016
40
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SP-BCN-05] / Check-in
Description
The Traffic Participant will be allowed to check-in to a parking system without
using an on-street ticketing-machine.
Goal
To improve the user experience by allowing to check-in to a parking system via
his/her smartphone without looking for a parking ticket machine nor using it.
Actor
Traffic Participant Dropping his car within a parking zone.
Data Provider
External Data Provider
S/A-Provider
External Check-in Provider / SEAT App
Smart Objects
Smart phone connected to SEAT Car via MirrorLink
Platforms
Some external Parking Company platform
Stakeholders
Traffic Participant, B:SM, SABA
Benefits
Traffic Participant does not have to look for a parking ticket vending machine
but can check in directly via his smartphone.
Annotations
Stories
© 2016
41
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SP-BCN-06] / Check-out
Description
The Traffic Participant will be allowed to check-out from a parking system without using an on-street ticketing-machine.
Goal
To improve the user experience by allowing to check-out from a parking system
via his/her smartphone without looking for a parking ticket machine nor using
it.
Actor
Traffic Participant leaving from a parking zone.
Data Provider
External Data Provider
S/A-Provider
External Check-out Provider / SEAT App
Smart Objects
Smart phone connected to SEAT Car via MirrorLink
Platforms
Some external Parking Company platform
Stakeholders
Traffic Participant, B:SM, SABA
Benefits
Traffic Participant does not have to look for a parking ticket vending machine
but can check-out directly via his smartphone.
Annotations
Maybe a candidate for Open Call with some innovative Start-Up
Stories
© 2016
42
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SP-BCN-07] / Pay for Stay
Description
The Traffic Participant will be allowed to pay for a parking service without using
an on-street ticketing-machine.
Goal
To improve the user experience by allowing to directly pay via his/her
smartphone without looking for a parking ticket machine nor using it.
Actor
Traffic Participant paying for a parking service.
Data Provider
External Data Provider
S/A-Provider
External Payment Provider / SEAT App
Smart Objects
Smart phone connected to SEAT Car via MirrorLink
Platforms
Some external Parking Company platform
Stakeholders
Traffic Participant, B:SM, SABA
Benefits
Traffic Participant does not have to look for a parking ticket vending machine
but can pay directly via his smartphone.
Annotations
Maybe a candidate for Open Call with some innovative Start-Up
Stories
© 2016
43
PART 2: PILOT USE CASE DESCRIPTIONS
1.3
D2.2.A ANNEX
Piedmont Pilot
The following four use cases are addressed in the Piedmont Pilot within the Smart Parking
use case cluster.
Fig. 13
Smart Parking Use Cases in Piedmont Pilot
© 2016
44
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SP-PIE-01] / Find Free Parking Spot, Smartphone App based
Description
Recommendation for parking spots based on location, availability and distance. This involves new parking spot observing smart objects.
Goal
The actor finds free parking stall(s).
Actor
Traffic Participant, Parking Detector
Data Provider
TBD: parking detector vendor (WorldSensing or other) and/or CSP
S/A-Provider
CSI Piemonte
Smart Objects
Parking spot detectors (real-time data)
Platforms
Smart Data Platform
Stakeholders
Local Municipality
City inhabitants
Benefits
Reduce search time for parking spots [traffic participant]
Reduce cost while searching for parking spots [traffic participant]
Reduce emissions through parking spot search times
Reduce congestion
Annotations
Stories
© 2016
45
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SP-PIE-04] / Route to Parking Spot
Description
Allow a User (Traffic Participant) to be routed directly to a parking spot or to his
final destination via a parking spot.
Goal
Showcase for seamless mobility.
Actor
Traffic Participant
Data Provider
TBD: parking detector vendor (WorldSensing or other) and/or CSP
S/A-Provider
CSI Piemonte
Smart Objects
Parking spot detectors (real-time data)
Platforms
Smart Data Platform
Stakeholders
City inhabitants
Benefits
Traffic participant: less searching time
City inhabitants: less congestion / park searching traffic
Annotations
Stories
© 2016
46
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SP-PIE-12] / Monitor Parking Spots, browser based
Description
Via a web browser, a Civil Service Employee monitors free parking spots on a
map.
Goal
Monitor geographical availability of free parking spots.
Actor
Civil Service Employee, Parking Detector
Data Provider
TBD: parking detector vendor (WorldSensing or other) and/or CSP
S/A-Provider
CSI Piemonte
Smart Objects
Parking spot detectors (real-time data)
Platforms
Smart Data Platform
Stakeholders
Traffic Participants
Benefits
A Civil Service Employee via web browser can monitor the on street situation in
the whole area.
Annotations
Stories
© 2016
47
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SP-PIE-20] / Monitor Parking Spots, App based
Description
Via a smartphone App, a Traffic Participant monitors free parking spots on a
map. It is possible to call SP-PIE-04 to get a route to the final parking spot.
Goal
Monitor geographical availability of free parking spots.
Actor
Traffic Participant, Parking Detector
Data Provider
TBD: parking detector vendor (WorldSensing or other) or CSP
S/A-Provider
CSI Piemonte
Smart Objects
Parking spot detectors (real-time data)
Platforms
Smart Data Platform
Stakeholders
Civil Service Employee
Benefits
A Traffic Participant can from his smartphone monitor the on street situation in
the whole area and decide where it makes sense to drive there.
Annotations
This UC is needed because Piedmont Pilot doesn't support parking spot reservation, In this way Users can choose to drive to the areas with most available
parking spots
Stories
© 2016
48
PART 2: PILOT USE CASE DESCRIPTIONS
2
D2.2.A ANNEX
Smart Traffic Management Use Case Cluster
The use case cluster Smart Traffic Management is addressed in the Barcelona Pilot, the
Piedmont Pilot and the Northern Germany Pilot.
2.1
Barcelona Pilot
The following six use cases are addressed in the Barcelona Pilot within the Smart Traffic
Management use case cluster.
Fig. 14
Smart Traffic Management Use Cases in Barcelona Pilot
© 2016
49
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[STM-BCN-01] / Get Traffic Information
Description
For a given area, information about travel times and speeds is shown at link
level
Goal
To have an overview about the travel times and speeds at link level at certain
selected area.
Actor
Traffic Information Center Operator
Data Provider
WorldSensing
SEAT
UPC (Synthetic Data obtained by simulation)
S/A-Provider
UPC
Smart Objects
Traffic sensors (Bluetooth/WIFI detectors, simulated loop detectors)
Smart Cars
Platforms
OpenIot, WorldSensing
Stakeholders
Barcelona City Council
Benefits
Knowledge of Traffic State
Annotations
This use case will use a Traffic Monitoring Service that will implement data filtering, map matching (for connected cars data) and estimate traffic variables
(travel times & speeds)
Stories
© 2016
50
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[STM-BCN-02] / Monitor Traffic Alarms
Description
For a given area or link, information about abnormal situations is pushed and
shown to the user
Goal
To alert the user about abnormal traffic situation in certain pre-defined area.
Actor
Traffic Information Center Operator
Data Provider
WorldSensing
SEAT
UPC (Synthetic Data obtained by simulation)
S/A-Provider
UPC
Smart Objects
Traffic sensors (Bluetooth/WIFI detectors, simulated loop detectors)
Smart Cars
Platforms
OpenIot, WorldSensing
Stakeholders
Barcelona City Council
Benefits
Knowledge of Traffic State
Annotations
This use case will use a Traffic Monitoring Service that will implement data filtering, map matching (for connected cars data) and estimate traffic variables
Stories
© 2016
51
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[STM-BCN-03] / Get Travel Times between two points
Description
For a given area, user can obtain an estimation of travel times between an
Origin and a Destination (from a predefined subset of O-D pairs).
Goal
To provide users with estimated travel times from origin to destination preselected pairs.
Actor
Traffic Information Center Operator
Data Provider
WorldSensing
SEAT
UPC (Synthetic Data obtained by simulation)
S/A-Provider
UPC
Smart Objects
Traffic sensors (Bluetooth detectors, simulated loop detectors)
Smart Cars
Platforms
OpenIot, WorldSensing
Stakeholders
Barcelona City Council
Benefits
Knowledge of Traffic State
Annotations
This use case will use a Traffic Monitoring Service that will implement data filtering, map matching (for connected cars data) and estimate traffic variables
Stories
© 2016
52
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[STM-BCN-04] / Monitor Environment Alarms
Description
For a given area or link, information about high air pollution/noise pollution
situations is pushed and shown to the user
Goal
To alert the user about critical pollution situations in certain pre-defined area or
set of links.
Actor
Traffic Information Center Operator
Data Provider
Barcelona City Council
SEAT
UPC (Synthetic Data obtained by simulation)
S/A-Provider
UPC
Smart Objects
City Noise Sensors
Smart Cars Air Quality Sensors
Platforms
OpenIot (for city sensors), Bezirk (for air quality sensors)
Stakeholders
Barcelona City Council
Benefits
Knowledge of Environment State
Annotations
This use case will use a Environment Monitoring Service that will implement a
pre-processing of data obtained from sensors
Stories
© 2016
53
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[STM-BCN-05] / Set Environment Recommendations
Description
For a given area or link, under high air pollution/noise pollution situations, recommendation son speed, circulation or parking may be established (i.e. no diesel cars, lower speed limits, banned areas for cars, incentive policies...).
Goal
To establish traffic recommendations for a certain area or set of links in order
to improve high pollution situations.
Actor
Traffic Participant
Data Provider
Barcelona City Council
SEAT
UPC (Synthetic Data obtained by simulation)
S/A-Provider
UPC
Smart Objects
City Noise Sensors
Smart Cars Air Quality Sensors
Platforms
OpenIot
Stakeholders
Barcelona City Council
Benefits
Improve City Air Quality and Noise levels
Annotations
This use case will use a Traffic Recommendations Management Service and
Environment Monitoring Service that will implement data filtering and preprocessing of data obtained from sensors
Stories
© 2016
54
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[STM-BCN-06] / Get Environment Recommendations
Description
For a given area or link, user can get active recommendations due to high risk
environment situations
Goal
To get traffic recommendations to the user for a certain area or set of links due
to high risk environment situations.
Actor
Traffic Information Center Operator
Data Provider
Barcelona City Council
SEAT
UPC (Synthetic Data obtained by simulation)
S/A-Provider
UPC
Smart Objects
City Noise Sensors
Smart Cars
Platforms
OpenIot
Stakeholders
Barcelona City Council
Benefits
Improve City Air Quality and Noise levels
Annotations
This use case will use a Traffic Recommendations Management Service
Stories
© 2016
55
PART 2: PILOT USE CASE DESCRIPTIONS
2.2
D2.2.A ANNEX
Piedmont Pilot
The following nine use cases are addressed in the Piedmont Pilot within the Smart Traffic
Management use case cluster.
Fig. 15
Smart Traffic Management Use Cases in Piedmont Pilot
© 2016
56
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[STM-PIE-01] / Get Traffic Information, via Browser
Description
Civil service employees get traffic information monitoring traffic conditions via
browser related the covered area
Goal
To have an overview about the traffic conditions related to the covered area
Actor
Civil service employee, Traffic counting sensors, Mobile Analytics
Data Provider
CSP
Vodafone
Econais - Wubby
S/A-Provider
CSI Piemonte
Smart Objects
Traffic counting sensors
Smartphones/cellphones (indirectly)
Platforms
Smart Data Platform
Stakeholders
Traffic Participants
City inhabitants
Benefits
To have a vision of the traffic conditions in order to improve the movements of
citizens
Annotations
Stories
© 2016
57
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[STM-PIE-02] / Monitor Traffic Alarms
Description
The system alerts users in case of dangerous traffic conditions
Goal
To alert civil service employee about dangerous traffic conditions in order to
involve public security
Actor
Civil service employee, Traffic counting sensors, Mobile Analytics
Data Provider
CSP
Vodafone
Econais - Wubby
S/A-Provider
CSI Piemonte
Smart Objects
Traffic counting sensors
Smartphones/cellphones (indirectly)
Platforms
Smart Data Platform
Stakeholders
Traffic Participants
City inhabitants
Public security
Benefits
To alert the civil service in case of dangerous situations about traffic jams
Stories
© 2016
58
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[STM-PIE-03] / Get Air Quality Conditions, via Browser
Description
Civil service employees get air quality monitoring air quality conditions via
browser related the covered area
Goal
To have an overview about the air quality conditions related to the covered
area
Actor
Civil service employee, Air Quality Station, Mobile Analytics
Data Provider
CSP
Vodafone
Econais - Wubby
S/A-Provider
CSI Piemonte
Smart Objects
Air Quality Station
Smartphones/cellphones (indirectly)
Platforms
Smart Data Platform
Stakeholders
Traffic Participants
City inhabitants
Benefits
To have a vision of the air quality conditions in order to improve the health of
citizens
Stories
© 2016
59
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[STM-PIE-04] / Monitor Environment Alarms, via Browser
Description
The system alerts users in case of emissions over the limit values
Goal
To alert civil service employee about emissions over the limit values in order to
involve public security
Actor
Civil service employee
Data Provider
CSP
Vodafone
Econais - Wubby
S/A-Provider
CSI Piemonte
Smart Objects
Air Quality Station
Smartphones/cellphones (indirectly)
Platforms
Smart Data Platform
Stakeholders
Traffic Participants
City inhabitants
Public security
Benefits
To alert the civil service in case of high air emissions
Stories
© 2016
60
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[STM-PIE-05] / Monitor Noise
Description
The system alerts users in case of emissions over the limit values
Goal
To alert civil service employee about emissions over the limit values in order
to involve public security
Actor
Civil service Employee, Traffic Counter Sensor
Data Provider
Vodafone
S/A-Provider
Vodafone
Smart Objects
Smartphones/cellphones (indirectly), noise sensor (to evaluate)
Platforms
Vodafone IoT Platform
Stakeholders
Traffic Participants
City inhabitants
Public Security
Benefits
To have a constant monitoring about a potentially critical event that can happen.
Stories
© 2016
61
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[STM-PIE-06] / Smart Waste Management Withdrawal
Description
Optimization of waste collection routes
Goal
Reduction of management costs, monitoring waste level and receiving alarm
when alarm level is reached.
Actor
Civil service Employee, Mobile Analytics, Waste Company
Data Provider
Vodafone
S/A-Provider
Vodafone
Smart Objects
Smartphones/cellphones (indirectly), Specific Sensor
Platforms
Vodafone IoT Platform
Stakeholders
Traffic Participants
City inhabitants
Benefits
Increasing the quality and quantity of the materials to be sent for recovery
Stories
© 2016
62
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[STM-PIE-07] / O/D matrices generation
Description
Match of trip makers’ origins and destinations to develop a “trip table”, a matrix that displays the number of trips going from each origin to each destination
including the expected reasons of the trip.
Goal
Provide the Urban Mobility Planner a global view on the trips during the day on
hourly basis
Actor
Urban Mobility Planner, Mobile Analytics
Data Provider
Vodafone
S/A-Provider
Vodafone
Smart Objects
Smartphones/cellphones (indirectly)
Platforms
Vodafone IoT Platform
Stakeholders
Traffic Participants
City inhabitants
Benefits
Get useful information over time on the traffic flow in the city
Stories
© 2016
63
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[STM-PIE-08] / Transportation modes
Description
Mode choice analysis match trips with the mode of transport used
Goal
Provide the Urban Mobility Planner the possibility the mode of transport used
in the city
Actor
Urban Mobility Planner, Mobile Analytics
Data Provider
Vodafone
S/A-Provider
Vodafone
Smart Objects
Smartphones/cellphones (indirectly)
Platforms
Vodafone IoT Platform
Stakeholders
Traffic Participants
City inhabitants
Benefits
Get useful information over time on the traffic flow in the city
Stories
© 2016
64
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[STM-PIE-09] / Transport modes Routes
Description
Hourly reconstruction of routes, route choice, or traffic assignment concerns the
selection of routes (alternative called paths) between origins and destinations in
transportation networks.
Goal
Provide the Urban Mobility Planner the possibility the routes together with mode
of transport and reason for trips used in the city
Actor
Urban Mobility Planner, Mobile Analytics
Data Provider
Vodafone
S/A-Provider
Vodafone
Smart Objects
Smartphones/cellphones (indirectly)
Platforms
Vodafone IoT Platform
Stakeholders
Traffic Participants
City inhabitants
Benefits
Get useful information over time on the traffic flow in the city
Stories
© 2016
65
PART 2: PILOT USE CASE DESCRIPTIONS
2.3
D2.2.A ANNEX
Northern Germany Pilot
ID
[STM-NG-01] / Smart Net Balancing
Description
Using Actual Traffic Data, this Use Case supports Traffic Centers by providing
suggestions for net-optimization of current traffic.
Goal
To improve traffic flow by striving towards a net optimum.
Actor
Traffic Information Center Software
Data Provider
TIC Berlin
S/A-Provider
VMZ Berlin
Smart Objects
Traffic Detectors (Traffic Volumes, Speed, LOS)
Platforms
VMZ TIC
Stakeholders
TIC, Road User
Benefits
Traffic Information Center Operator gets Content for Information devices
Road User gets information for optimized behavior on his journey based on net
optimum
Annotations
Optional use case, with lowest priority.
Stories
© 2016
66
PART 2: PILOT USE CASE DESCRIPTIONS
3
D2.2.A ANNEX
Public Transport Optimization Use Case Cluster
The use case cluster Public Transport Optimization is addressed in the Northern Germany
Pilot.
3.1
Northern Germany Pilot
The following eight use cases are addressed in the Northern Germany Pilot within the Public
Transport Optimization use case cluster.
Fig. 16
Public Transport Optimization Use Cases in Northern Germany Pilot
© 2016
67
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[PTO-NG-01] / Optimize public transport resources
Description
City administration or public transport provider can reorganize number of buses/trains based on number of people in area or number of people on PT.
Goal
To make information about public transport load available to public transport
providers, along with information about people density in the city.
This can be used to make informed decisions of reorganization of public
transport.
Actor
City administration or public transport provider
Data Provider
WAG - Information about number of devices registered at different access points
(People density estimation, based on information about number of people on
the bus, collected via mobile sensors on buses, and number of people in area)
S/A-Provider
AAU / WAG
Smart Objects
Smart devices sensed using Wi-Fi probe catching from mobile sensor on bus
Smart devices connected to the Wolfsburg WLAN
Platforms
WLAN infrastructure Wolfsburg
Bosch Smart City
Stakeholders
City council
Public transport provider
Benefits
Reduce wasted resources in terms of empty buses driving around
Increase public transport users satisfaction
Stories
© 2016
68
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[PTO-NG-02] / Optimize public transport selection/guidance
Description
User can select bus or train line based on information of current traveler load,
or predicted load based on people densities in source and destination areas.
Goal
To make the travelers decision of which public transport option to choose more
informed, based on information of the user density in the areas that the traveler is traveling to and from, and based on the number of current travelers.
Actor
Public transportation user
Data Provider
WAG - Information about number of devices registered at different access
points (People density estimation, based on information about number of people on the bus, collected via mobile sensors on buses, and number of people in
area)
S/A-Provider
AAU / WAG
Smart Objects
Smart devices connected to the Wolfsburg WLAN
Smart devices sensed using Wi-Fi probe catching from mobile sensor on bus
Platforms
WLAN infrastructure Wolfsburg
Bosch Smart City Platform
Stakeholders
Public transport user
Benefits
Traveler can avoid waiting for a bus/train that is filled, and therefore cannot
ride
Travel planer provider can add more intelligence to the travel plan suggestions
Stories
© 2016
69
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[PTO-NG-03] / Optimize end-user experience at public transport stop
Description
User will be informed when reaching the public transport stop (e.g. bus stop)
about up-to-date schedule information (e. g. B103 in 3 minutes, B115 in 6
minutes). This information is provided by a local service (e.g. running on a
Raspberry Pi) and local connectivity to the end-users smartphone and displayed
by an App.
Goal
To provide the user with up-to-date schedule information conveniently from
the smart phone. Automatic reminder will be provided to the user based on
real-time scheduling information. This will improve the user experience of taking public transport.
Actor
Public transportation user
Data Provider
WAG (Up-to-date schedule information (T.B.C.))
S/A-Provider
Service Provider: WAG
(Bosch CR develops the App based on the BEZIRK Platform)
Smart Objects
BEZIRK Smart Object Platform
Platforms
WAG Platform with real-time public transport information
BEZIRK Smart Object Platform
Stakeholders
Public transport user
Public transport providers
Benefits
Traveler can be relaxed when arriving at the public transport stop, as s/he will
receive reliable, up-to-date scheduling information
Traveler does not get worried/annoyed when delays occur and there is no need
to look-up schedule information manually
Stories
© 2016
70
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[PTO-NG-04] / Optimize end-user experience when taking public transport
Description
User will be informed when taking public transport (e.g. a bus or tram) about
real-time travel information (e. g. Stop at Location X in 3 minutes, Stop at Location Y in 6 minutes). This information is provided by a local service (e.g. running
on a Raspberry Pi) and local connectivity to the end-users smartphone and displayed by an App.
Goal
To provide the user with real-time travel information conveniently on the
smartphone. Automatic reminder will be provided to the user upon arrival of
the predicted/selected stop. This will improve the user experience of taking
public transport.
Actor
Public transportation user
Data Provider
WAG in cooperation with AAU (Real time travel information (T.B.C.))
S/A-Provider
Service Provider: WAG
(Bosch CR develops the App based on the BEZIRK Platform)
Smart Objects
BEZIRK Smart Object Platform
Platforms
WAG Platform with real-time public transport information
BEZIRK Smart Object Platform
Stakeholders
Public transport user
Public transport providers
Benefits
Traveler can be relaxed when riding the public transport, as the user will be
able to view real-time travel information at any time
Traveler does not get worried to miss his stop or get annoyed when delays occur
Stories
© 2016
71
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[PTO-NG-06] / Live bus tracking
Description
To be able to track the location of buses live. This will enable public transport
providers to monitor if buses are on schedule or are deviating. Furthermore, by
making this information public it can be used in travel assistance and guide
apps, that can tell the user when the next bus will arrive, based on live information about the location of the bus.
Goal
To obtain live tracking of buses
Actor
Public transport provider, Buses, public transport users
Data Provider
WAG together with AAU - the GPS location of buses in real time (Live GPS location information from smart sensors on buses)
S/A-Provider
WAG
AAU
Smart Objects
Smart buses
Platforms
AAU / Bosch Smart City platform
Stakeholders
Public Transport Provider
Benefits
Obtain live information about buses to provide additional services in case of
delays.
Stories
© 2016
72
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[PTO-NG-07] / People density estimation based on smart buses
Description
By exploiting the smart buses driving around and covering most of a city, we will
use the smart buses as people density sensors. This will give a very interesting
image of the density of people in the city, as it will not just be sensed at one or
more fixed positions, but will be sensed at different locations all over the city at
different times. This information can be used in a wide range of contexts, both in
providing information of where there are many people, but also about where
there are few people.
Goal
obtain estimates of number of people in the areas where the bus passes through
Actor
Public transport provider
Smart buses
Data Provider
WAG - information about the number of people in the areas where the bus passes, based on number of devices (People density estimation, based on number of
devices registered by smart sensors on buses)
S/A-Provider
WAG; AAU
Smart Objects
Smart buses
Platforms
AAU
Bosch Smart City platform
Stakeholders
Public transport provider
Benefits
Public transport provider receives information about the movement of users and
of potential optimization of their bus lines provided.
Stories
© 2016
73
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[PTO-NG-08] / Identification of people flow along bus line
Description
To be able to identify where, and if, there are big flows of people. This can be
used by e.g. the authorities to see where large crowds are going and act accordingly.
Based on the number of devices registered by the mobile sensor in buses and in
combination with the public Wi-Fi the transport provider can optimize its bus
lines and is able to adapt additionally services.
Goal
To obtain estimate of people movement along the bus line
Actor
Smart buses
Data Provider
WAG - based on input from PTO-NG-07 (People density estimation and people
movement, based on number of devices registered by smart sensors on buses)
S/A-Provider
WAG
AAU
Smart Objects
Smart buses
Platforms
AAU
Bosch Smart City platform
Stakeholders
Public transport providers
Benefits
Public transport provider receives information about the movement of users
and of potential optimization of their bus lines provided. Additionally they get
information (heat map) of most frequented places/ areas and less frequented.
Stories
© 2016
74
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[PTO-NG-09] / Creating a model for prediction of bus utilization
Description
We want to be able to predict the utilization of the buses. This can be done by
over a period counting the number of people on the bus, and following give a
prediction of how many people will be on the bus, depending on time of day,
day of week, bus line, destination, etc.
This will be of use for the public transport provider in deciding if to insert an
extra bus on a route at a specific time. It will also be of use for the public
transport user in knowing if a specific bus during the day will probably be high
loaded, why if possible it might be nicer to delay traveling 10-15 minutes.
Based on the number of devices registered by the mobile sensor in buses and in
combination with the public Wi-Fi the transport provider can optimize its bus
lines and is able to adapt additionally services. There has to be developed an
algorithm based on registered devices and real number of persons using bus
lines.
Goal
To obtain an estimate of the number of passengers on the bus in real time
Actor
Smart buses, public transport provider
Data Provider
WAG - information about the number of people on the bus, based on counted
devices (People density estimation, based on number of devices registered by
smart sensors on buses)
S/A-Provider
WAG, AAU
Smart Objects
Smart buses
Platforms
AAU; Bosch Smart City platform
Stakeholders
Public transport provider
Benefits
Public transport provider is able to optimize its bus lines regarding capacity and
frequency of use.
Stories
© 2016
75
PART 2: PILOT USE CASE DESCRIPTIONS
4
D2.2.A ANNEX
Healthy Bike Navigation Use Case Cluster
The use case cluster Healthy Bike Navigation is addressed in the Piedmont Pilot.
4.1
Piedmont Pilot
The following two use cases are addressed in the Piedmont Pilot within the Healthy Bike
Navigation use case cluster.
Fig. 17
Healthy Bike Navigation Use Cases in Piedmont Pilot
© 2016
76
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[HBN-PIE-01] / Find Healthier Route
Description
Bikers can get an overview of healthier route between two points in town.
Goal
Promote usage of alternative transportation means (bicycle and foot), with
traffic and environmental monitoring.
Actor
Bikers, Air quality stations, Traffic counting sensors, Router.
Data Provider
CSP
Econais
S/A-Provider
CSI Piemonte
Smart Objects
Air quality stations
Traffic counting sensors
Smartphones/cellphones (indirectly)
Platforms
Smart Data Platform
Econais / Wubby
Stakeholders
City inhabitants
Benefits
Improve usage of alternative transportation means. Reduce pollution.
Annotations
The routing algorithm takes into account pollutants distribution and traffic
information.
Stories
© 2016
77
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[HBN-PIE-02] / Navigate to Destination through Healthier Route
Description
Navigate a healthier route between two points in town. For bikers and pedestrians.
Goal
Reach destination though healthier route.
Actor
Biker, Router
Data Provider
HBN-PIE-01
S/A-Provider
CSI Piemonte
Smart Objects
No
Platforms
TBD
Stakeholders
City inhabitants.
Benefits
Improve usage of alternative transportation means. Reduce pollution. Improve inhabitants’ health.
Annotations
Stories
© 2016
78
PART 2: PILOT USE CASE DESCRIPTIONS
5
D2.2.A ANNEX
Smart Bike Sharing Use Case Cluster
The use case cluster Smart Bike Sharing is addressed in the Piedmont Pilot.
5.1
Piedmont Pilot
The following four use cases are addressed in the Piedmont Pilot within the Smart Bike Sharing use case cluster.
Fig. 18
Smart Bike Sharing Use Cases in Piedmont Pilot
© 2016
79
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SBS-PIE-01] / Docks and bikes availability
Description
Bikers find available docks to park the bike or free bikes
Goal
Bikers have information about the availability of docks in the city and about
free bikes in the city
Actor
Bikers, Bike Sharing Station
Data Provider
CSP
Third party of bike sharing company
S/A-Provider
CSI Piemonte
Smart Objects
Bike sharing station
Platforms
Smart Data Platform
Stakeholders
City inhabitants
Benefits
To reduce time to find docks for bikers
To incentivize the use of bike sharing
Annotations
Stories
© 2016
80
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SBS-PIE-02] / Estimate bike availability
Description
Bikers get an estimation about the availability of bikes using historical data
series
Goal
Bikers get an estimation about the availability of bikes using historical data
series
Actor
Bikers, Bike Sharing Station, Connected bikes through rider's smartphones,
People Density Estimation
Data Provider
CSP
CSI Piemonte
Vodafone
Third party of bike sharing company
S/A-Provider
CSI Piemonte
Smart Objects
Bike Sharing Station, Connected bikes through rider's smartphones
Platforms
Smart Data Platform
Vodafone Mobile Analytics Platform
Stakeholders
City inhabitants
Benefits
To reduce time to find bikes
To incentivize the use of bike sharing
Annotations
Stories
© 2016
81
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SBS-PIE-03] / Estimate open dock availability
Description
Bikers get an estimation about the availability of open docks using historical
data series
Goal
Bikers get an estimation about the availability of open docks using historical
data series
Actor
Bikers, Bike Sharing Station, Connected bikes through rider's smartphones,
People Density Estimation
Data Provider
CSP
CSI Piemonte
Vodafone
Third party of bike sharing company
S/A-Provider
CSI Piemonte
Smart Objects
Bike Sharing Station, Connected bikes through rider's smartphones
Platforms
Smart Data Platform
Vodafone Mobile Analytics Platform
Stakeholders
City inhabitants
Benefits
To reduce time to find open docks
To incentivize the use of bike sharing
Annotations
Stories
© 2016
82
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SBS-PIE-04] / Locate bike
Description
Riders on bikes help to locate the bikes in use
Goal
Bikers get information about the shared bikes in use
Actor
Bikers, Connected bikes through rider's smartphones,
Data Provider
CSP
CSI Piemonte
S/A-Provider
CSI Piemonte
Smart Objects
Connected bikes through rider's smartphones
Platforms
Smart Data Platform
Stakeholders
City inhabitants
Benefits
To reduce time to find bikes
To incentivize the use of bike sharing
Annotations
Stories
© 2016
83
PART 2: PILOT USE CASE DESCRIPTIONS
6
D2.2.A ANNEX
Incentive Based Green Route Planning Use Case Cluster
The use case cluster Incentive Based Green Route Planning is addressed in the Barcelona
Pilot and the Piedmont Pilot.
6.1
Barcelona Pilot
The following three use cases are addressed in the Barcelona Pilot within the Incentive
Based Green Route Planning use case cluster.
Fig. 19
Incentive Based Green Route Planning Use Cases in Barcelona Pilot
© 2016
84
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[GRP-BCN-01] / Find Green Routes
Description
Routing best recommendation based on various parameters (estimated time,
cost, environmental sustainability). If there are areas in a state of emergency
because of pollution then user can discard driving routes and get recommendations to drive outside restricted areas to parking places available, and continue
by public transport to the destination.
Goal
To get recommendations to the user with respect to alternative routes or
modes in order to avoid certain areas that are in emergency state due to high
pollution levels.
Actor
Mobility user
Data Provider
WorldSensing; SEAT (from Car); UPC (Synthetic Data obtained by simulation);
Barcelona City Council
S/A-Provider
UPC
Smart Objects
Traffic sensors (Bluetooth detectors, simulated loop detectors)
Pollution sensor in car (connected to BEZIRK smartphone)
Other data from car (geo location, ...)
Platforms
OpenIot, WorldSensing, BEZIRK
Stakeholders
Barcelona City Council
Benefits
To reduce private vehicle traffic in critical areas.
Annotations
This use case will use a Traffic Monitoring Service that will implement data filtering, map matching (for connected cars data) and estimate the required traffic variables...
Stories
© 2016
85
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[GRP-BCN-02] / Get Alternative Transport modes
Description
For a given destination give alternatives to travel by public transport
Goal
To get alternative public transport routes to arrive to pre-defined destination
in certain area.
Actor
Mobility User
Data Provider
TMB (Open Data)
S/A-Provider
UPC
Smart Objects
Smart Phone, Smart Cars
Platforms
external
Stakeholders
Barcelona City Council, Transport Metropolitans de Barcelona (BCN)
Benefits
Real Time information on public transport alternatives (bus updated schedule)
Annotations
This use case will use an external Public Transport Information Service
Stories
© 2016
86
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[GRP-BCN-03] / Follow Green Recommendations
Description
Track user
Goal
To track users in order to evaluate if they are following the proposed green
recommendations or not.
Actor
User
Data Provider
External Data Provider
S/A-Provider
UPC
Smart Objects
Smart phones
Smart Cars
Platforms
OpenIot (and possibly BEZIRK)
Stakeholders
Barcelona City Council, TMB
Benefits
Get incentives
Annotations
This use case will use a Traffic Monitoring Service that will implement data
filtering, map matching (for connected cars data) and estimate the required
traffic variables
Stories
© 2016
87
PART 2: PILOT USE CASE DESCRIPTIONS
6.2
D2.2.A ANNEX
Piedmont Pilot
The following five use cases are addressed in the Piedmont Pilot within the Incentive Based
Green Route Planning use case cluster.
Fig. 20
Incentive Based Green Route Planning Use Cases in Piedmont Pilot
© 2016
88
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[GRP-PIE-01] / Find Green Routes
Description
TBW: Routing best recommendation based on various parameters (estimated
time, cost, environmental sustainability). If there are areas in a state of emergency because of pollution then user can discard driving routes and get recommendations to drive outside restricted areas to parking places available, and
continue by public transport to the destination.
Goal
TBW
Actor
Mobility user
Data Provider
CSP; Vodafone; Econais - Wubby
S/A-Provider
CSI Piemonte
Smart Objects
Traffic counting sensors; Air quality stations
Platforms
CSI Smart Data Platform; Vodafone; Econais - Wubby
Stakeholders
City Councils, City inhabitants
Benefits
Reduce automotive traffic in critical areas.
Annotations
This use case will use a Traffic Monitoring Service that will implement data filtering, map matching (for connected cars data) and estimate the required traffic variables. STM-PIE-01. STMP-PIE-04
Stories
© 2016
89
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[GRP-PIE-02] / Get Alternative Transport modes
Description
For a given destination give alternatives to travel by public transport
Goal
Actor
Mobility User
Data Provider
Public Transport Operators
S/A-Provider
CSI Piemonte
Smart Objects
No
Platforms
CSI Smart Data Platform
Stakeholders
City Councils, Public Transport Operators
Benefits
Incentivize the use of public transport
Annotations
Stories
© 2016
90
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[GRP-PIE-03] / Follow Green Recommendations
Description
Track user
Goal
Reach destination with route with less traffic and less pollution
Actor
User
Data Provider
GRP-PIE-01
S/A-Provider
CSI Piemonte
Smart Objects
Smart phones
Platforms
CSI Smart Data Platform
Stakeholders
City council. City inhabitants.
Benefits
Harmonize traffic conditions and minimize air emissions. Get virtual incentives.
Annotations
TBW! This use case will use a 'Traffic Recommendations Management Service'
that will implement data filtering, map matching (for connected cars data) and
estimate the required traffic variables
Stories
© 2016
91
PART 2: PILOT USE CASE DESCRIPTIONS
7
D2.2.A ANNEX
Multimodal Route Optimization Use Case Cluster
The use case cluster Multimodal Route Optimization is addressed in the Northern Germany
Pilot.
7.1
Northern Germany Pilot
The following nine use cases are addressed in the Northern Germany Pilot within the Multimodal Route Optimization use case cluster.
Fig. 21
Multimodal Route Optimization Use Cases in Northern Germany Pilot
© 2016
92
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[MRO-NG-01] / Initial Intermodal Routing Start to Destination
Description
For a given start to destination relation, multiple routes are calculated. The
result represents the best routes for several modes as well as suitable intermodal routes. Historic traffic- and incident-information can be included in the
calculation.
Goal
Improvement of multimodal route calculation to long distance results
Actor
Traffic Participant (Long Distance Commuter)
Data Provider
several mode-specific router:
long distance public transport (DB),
long distance individual transport (TomTom)
S/A-Provider
VMZ Berlin
Smart Objects
Platforms
VMZ TIC Platform
Stakeholders
Commuters
Inhabitants (general public)
Benefits
traffic participant (commuter): knowledge of best route
general public: reduction of unnecessary traffic
Annotations
The initial route calculation and collection is base for further use cases in MROClusters
Stories
© 2016
93
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[MRO-NG-02] / Save Multimodal Route
Description
After initially calculating one or different multimodal routes, they can be saved
in a personalized environment (user account).
Goal
Keeping information for day to day observation of routes.
Actor
Traffic Participant (Commuter)
Data Provider
VMZ
S/A-Provider
VMZ
Smart Objects
Multimodal Routes
Platforms
VMZ TIC
Stakeholders
Commuter
Benefits
A traffic participant can load and view his predefined routes without new navigation.
Routes are stored for further processing.
Annotations
user account must be existent
Stories
© 2016
94
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[MRO-NG-03] / Monitor Street Traffic Situation
Description
Previously calculated or saved routes on highways can be monitored with regard to changes in traffic situation or occurrence of traffic incidents.
Goal
Creating an environment in which the traffic situation for highway routes can
be observed.
Actor
Route Monitoring Service
Data Provider
Floating Car Data Provider
Stationary Traffic Sensor Operator
Landesmeldestelle (incident message provider)
S/A-Provider
VMZ
Smart Objects
FCD Travel Times
Stationary Sensors LOS
Incident messages
Platforms
VMZ TIC Platform (TTE)
Stakeholders
Commuter
Benefits
Commuter gets an information about incidents on his routes
Annotations
Stories
© 2016
95
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[MRO-NG-04] / Monitor Rail Situation
Description
Observe the operational situation on railway - relations for previously calculated or saved routes.
Goal
Creating an environment in which the traffic situation for rail routes can be
observed.
Actor
Route Monitoring Service
Data Provider
Deutsche Bahn
S/A-Provider
VMZ
Smart Objects
Incident Messages
Platforms
VMZ TIC
Stakeholders
Commuter
Benefits
Commuter gets information about delay / incidents on routes.
Annotations
Stories
© 2016
96
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[MRO-NG-05] / Detour
Description
Based on an incident, this use case creates an opportunity for the commuter to
avoid massive delays by rerouting his journey, e.g. to a different mode or on a
different path.
Goal
Automatic handling of incidents for the commuter.
Actor
Detour Service
Data Provider
Traffic Observation Service
Multimodal Routing Service
S/A-Provider
VMZ
Smart Objects
Incidents
Traffic Conditions (Flow Times)
Platforms
VMZ TIC
Stakeholders
Commuter
Benefits
Commuter gets information about possible detours or recommendations for a
modal shift in case of incidents on his daily routes and can avoid getting stuck.
Annotations
Stories
© 2016
97
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[MRO-NG-06] / Find Alternative Vehicle
Description
Allow user to quickly find an alternative vehicle to start or finalize his journey
despite an incident.
Goal
Showcase seamless mobility also in case of incidents.
Actor
traffic participant (commuter)
Data Provider
car sharing provider
S/A-Provider
VMZ
Smart Objects
locations of car sharing cars
Platforms
VMZ TIC
Stakeholders
Commuter
Benefits
Commuter gets information about availability of car sharing cars on his routes
if, because of an incident, his preferred mode (e. g. train) is not available.
Annotations
For later stage
Stories
© 2016
98
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[MRO-NG-07] / Reserve Alternative Vehicle
Description
Allow the commuter to reserve a found car sharing vehicle to start or resume
his journey in case of an incident.
Goal
Demonstrating the seamless integration of car sharing car in his journey plan in
case of an incident.
Actor
Commuter
Data Provider
car sharing provider
S/A-Provider
VMZ
Smart Objects
Reservation status of car sharing cars
Platforms
VMZ TIC
Stakeholders
commuter, car sharer
Benefits
Commuter can seamlessly book a car to resume his journey
Annotations
Later stage or Open Call
Stories
© 2016
99
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[MRO-NG-08] / Check State of Relations
Description
The commuter will be enabled to check the actual condition on his saved relations.
Goal
Giving the commuter a possibility to check the actual state (traffic condition)
Actor
Commuter
Data Provider
Route Monitoring Service
S/A-Provider
VMZ
Smart Objects
Travel Times, Incident Messages
Platforms
VMZ TIC
Stakeholders
commuter
Benefits
The commuter has a direct overview on the current traffic situation on his alternatives routes and modes.
Annotations
Stories
© 2016
100
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[MRO-NG-09] / Inform Commuter about Deviation
Description
The service informs a commuter about a deviation of plan (e. g. change in timetable of train, congestion on highway) via a push notification
Goal
Showcase the push-notification of commuters in case of incidents on saved
routes or actual routings.
Actor
Commuter
Data Provider
Route Monitoring Service / Detour Service
S/A-Provider
VMZ
Smart Objects
travel times, incident messages
Platforms
VMZ TIC
Stakeholders
Commuter, other traffic participants
Benefits
commuter gets informed about incidents before he reaches an decision point,
commuter can evaluate options early
Annotations
Later stage implementation planned
Stories
© 2016
101
PART 2: PILOT USE CASE DESCRIPTIONS
8
D2.2.A ANNEX
Smart Charging Use Case Cluster
The Smart Charging use case cluster is only addressed within the Northern Germany Pilot.
8.1
Northern Germany Pilot
The following six use cases are addressed in the Northern Germany Pilot within the Smart
Charging use case cluster.
Fig. 22
Smart Charging Use Cases in Northern Germany Pilot
© 2016
102
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SC-NG-01] / Find Free Charging Station
Description
Recommendation of charging station based on location, availability and distance
Goal
Make data of smart objects “charging stations” available via BIG IoT API.
Actor
traffic participant
Data Provider
different charging point operators in Berlin and Wolfsburg
S/A-Provider
VMZ / WAG
Smart Objects
charging points
Platforms
VMZ TIC,
Bosch Smart City Platform
Stakeholders
E car driver
Benefits
Reduce search times for charging infrastructure
Increase user comfort by finding free charging station
Annotations
Stories
© 2016
103
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SC-NG-02] / Reserve Charging Infrastructure
Description
Make a reservation of a charging station for a specific period of time.
Goal
Showcase seamless mobility by connecting functionality of different providers
Actor
E car driver
Data Provider
various charging infrastructure operators, Siemens (Parking Detector)
S/A-Provider
VMZ
Smart Objects
charging infrastructure, parking sensors
Platforms
VMZ TIC
Some external charging station booking service platform
Stakeholders
E car driver
charging point operator
Benefits
User gets a charging point for sure if he needs one.
Annotations
For later stage or Open Call, use case implementation is only possible in private
space, regulatory and technical possibilities for implementation are still in
clearance.
Stories
© 2016
104
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SC-NG-03] / Route to Charging Infrastructure
Description
Allow a user (traffic participant) to directly route to an available charging point
or to his final destination via a charging point taking actual availability into account.
Goal
Showcase for seamless mobility with integration of charging infrastructure
Actor
E car driver (traffic participant)
Data Provider
various charging point operators,
traffic situation providers,
parking data provider (Siemens)
S/A-Provider
VMZ
WAG
Smart Objects
charging points, parking detectors, traffic detectors, FCD
Platforms
VMZ TIC, Bosch Smart City Platform
Stakeholders
E car driver
Charging point operator
Benefits
User can directly route to a free charging station taking actual traffic situation
into account.
Annotations
Stories
© 2016
105
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SC-NG-04] / Pay For Charge
Description
The e car driver will be allowed to pay for his charging action using his smart
phone.
Goal
showcase the seamless integration of all charging - relevant processes within
the use case cluster
Actor
Traffic participant (e car driver) charging his car on a commercial charging point
Data Provider
Smartphone, charging point operator
S/A-Provider
Some external billing provider
Smart Objects
Charging station
Platforms
Some external charging station backend and billing provider platform
Stakeholders
E car driver
Benefits
E car driver can save time by doing all charging related actions via an app instead of different RFID cards.
Annotations
For later stage or Open Call, regulatory and technical possibilities have to be
cleared yet.
Stories
© 2016
106
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SC-NG-11] / Observe Charging Infrastructure from Desk
Description
Via an online-GUI, a charging infrastructure enforcement officer shall be given
high level overviews of parking violations in his area in order to improve efficiency and impact of charging point enforcement.
Goal
Showcase integration of data of different data providers via BIG IoT API for different services / applications.
Actor
regulatory agency employee / supervisor
Data Provider
charging point operators / Siemens (Parking Detectors)
S/A-Provider
VMZ
Smart Objects
charging points / parking detectors
Platforms
VMZ TIC
Stakeholders
City council
traffic participants
Benefits
Civil service employee can monitor situation from desk and decide on best
(most efficient) ways for enforcement routes.
Annotations
For later stage
Stories
© 2016
107
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[SC-NG-12] / Observe Infrastructure On-Street
Description
Via A mobile device App (e.g. on a tablet-pc), a charging point enforcement
officer shall be given low level observation information of parking situation,
violations and basics.
Goal
Showcase integration of data of different data providers via BIG IoT API for different services / applications.
Actor
Civil service employee
Data Provider
charging point operators, Siemens (Parking Detectors)
S/A-Provider
VMZ
Smart Objects
charging points, parking sensors
Platforms
Siemens APM, VMZ TIC
Stakeholders
civil service employees
Traffic Participants
Benefits
Civil service employee can monitor the on street situation and decide on best
(most efficient) ways for enforcement routes.
Stories
Annotations
For later stage
© 2016
108
PART 2: PILOT USE CASE DESCRIPTIONS
9
D2.2.A ANNEX
Device To Device Communication Use Case Cluster
The use case cluster Device to Device Communication is addressed in the Barcelona Pilot.
9.1
Barcelona Pilot
The following two use cases are addressed in the Barcelona Pilot within the Device to Device
Communication use case cluster.
Fig. 23
Device to Device Communication Use Cases in Barcelona Pilot
© 2016
109
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[D2D-BCN-01] / Pedestrian - Traffic Light Interactions
Description
Pedestrians configure the kind of notifications they want to receive:
Green Light Time: Duration of the Green Light
Red Light Time: Duration of the Red Light
Only Nearest Traffic Light: Show only the time of the nearest Traffic Light or all
Near Lights (...) and their Special Needs (blind, handicaps, ...) kind of behavior
they need for the Traffic Light: Remote Push Button
Adapt Green Time: The Traffic Light will extend the Green Light time for crossing.
Crossing Advice: Advice for crossing from side to side through a crosswalk. Advice will be adapted to special user needs (i.e. vibration for blind people)
Approaching Advice: Advice for approaching a Traffic Light from the sidewalk.
Not enough time for Crossing
After all the configuration when a Traffic Light is near, the app will:
Receive Push notifications with the desired information.
Automatically ask for Adapting Green Time if it was previously configured.
Give Advice to the pedestrian if it was previously configured.
Goal
Actor
Pedestrian
Data Provider
Traffic Lights (schedules) and User Data (location, path, direction)
S/A-Provider
City Council (UPC?)
Smart Objects
Traffic Lights
Smartphone
Platforms
BEZIRK
Stakeholders
Citizens
Benefits
Support elderly, disabled, etc. people
Speed-up traffic light passing
Stories
© 2016
110
PART 2: PILOT USE CASE DESCRIPTIONS
D2.2.A ANNEX
ID
[D2D-BCN-02] / Cycler- Traffic Light Interactions
Description
Cyclers configure the kind of notifications they want to receive:
Green Light Time: Duration of the Green Light
Red Light Time: Duration of the Red Light
Only Nearest Traffic Light: Show only the time of the nearest Traffic Light or all
Near Lights (...) and the kind of behavior they need for the Traffic Light:
Give Priority: The Traffic Light will switch to Green when a cycler is approaching.
Extend Green Time: The Traffic Light will extend the Green Light time for crossing. Approaching Advice: Advice for approaching a Traffic Light from the sidewalk. Green Light Prioritization Route: Modify the route to the nearest Green
Light without deviating much from the route. (...) After the entire configuration
when a Traffic Light is near, the app will: Receive Push notifications with the
desired information. Automatically ask for Green Time Extensions and/or Priority if it was previously configured. Give Advice to the cycler and modify the route
if it was previously configured.
Goal
Actor
Cyclers
Data Provider
Traffic Lights (schedules) and User Data (location, path, direction)
S/A-Provider
City Council (UPC?)
Smart Objects
Traffic Lights
Smartphone
Platforms
BEZIRK
Stakeholders
Citizens
Benefits
Speed-up traffic light passing (e.g. through prioritization)
Stories
© 2016
111
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
Part 3:
D2.2.A ANNEX
High Level Service Descriptions
Part 3 of the Annex contains the high level service descriptions. For each service a description is presented using the template table on page 114.
The following table of contents shows the described services, structured by use case clusters. Services can be addressed in several use case clusters. Therefore, within the following
structure they are assigned to their main use case cluster and not repeated in other clusters
they may appear.
The following list of services reflects the current state of work and may be subject to modifications or additions in the upcoming pilot specification (WP 5, Task 5.1)
Table of Contents Part 3: High Level Service Descriptions
TEMPLATE FOR SERVICE DESCRIPTIONS .............................................................................. 114
1
SMART PARKING RELATED SERVICES ........................................................................ 115
PARKING AVAILABILITY SERVICE .................................................................................... 115
ROUTE TO PARKING SPOT SERVICE ............................................................................... 116
RESERVATION OF PARKING SPOT SERVICE..................................................................... 116
PARKING PREDICTIVE SERVICE ...................................................................................... 117
CHECK-IN / CHECK-OUT PAYMENT SERVICE ................................................................... 118
PARKING ENFORCEMENT SERVICE ................................................................................ 119
2
SMART TRAFFIC MANAGEMENT RELATED SERVICES..................................................... 120
TRAFFIC MONITORING SERVICE .................................................................................... 120
ENVIRONMENT MONITORING SERVICE ......................................................................... 121
TRAFFIC RECOMMENDATIONS MANAGEMENT SERVICE ................................................ 122
ANALYTIC SERVICES FOR TRAFFIC MANAGEMENT - O/D TABLE...................................... 123
ANALYTIC SERVICES FOR TRAFFIC MANAGEMENT - PEOPLE DENSITY AT POI.................. 123
ANALYTIC SERVICES FOR TRAFFIC MANAGEMENT -HISTORICAL PEOPLE DENSITY AT POI 124
ANALYTIC SERVICES FOR TRAFFIC MANAGEMENT - ROAD TRAFFIC INFORMATION ........ 124
ANALYTIC SERVICES FOR TRAFFIC MANAGEMENT - AREA TRAFFIC INFORMATION ......... 125
ANALYTIC SERVICES FOR TRAFFIC MANAGEMENT - MOBILITY PATTERNS ...................... 125
ANALYTIC SERVICES FOR TRAFFIC MANAGEMENT - CELLULAR DATA CROSS CORRELATION
WITH EXTERNAL DATA SOURCES................................................................................... 126
3
PUBLIC TRANSPORT OPTIMIZATION RELATED SERVICE.................................................. 127
PEOPLE DENSITY ESTIMATION ON BUS SERVICE ............................................................ 127
PEOPLE DENSITY ESTIMATION IN AREA SERVICE............................................................ 128
LIVE BUS POSITION SERVICE.......................................................................................... 128
© 2016
112
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
D2.2.A ANNEX
4
HEALTHY BIKE NAVIGATION RELATED SERVICES .......................................................... 129
5
SMART BIKE SHARING RELATED SERVICES ................................................................. 130
DOCK AND BIKES AVAILABILITY SERVICE........................................................................ 130
DOCK AND BIKE ESTIMATION SERVICE .......................................................................... 130
6
INCENTIVE BASED GREEN ROUTE PLANNING RELATED SERVICES ..................................... 131
ROUTING SERVICE ........................................................................................................ 131
INCENTIVE MANAGEMENT SERVICE .............................................................................. 132
7
MULTIMODAL ROUTE OPTIMIZATION RELATED SERVICES ............................................. 133
PERSONALIZATION SERVICE .......................................................................................... 133
MULTIMODAL ROUTING SERVICE (FOR CORRIDOR B-WOB) ........................................... 134
ROUTE MONITORING SERVICE ...................................................................................... 135
CAR SHARING RESERVATION SERVICE ........................................................................... 135
INCIDENT NOTIFICATION SERVICE ................................................................................. 136
DETOUR / MODE SHIFT RECOMMENDATION SERVICE ................................................... 136
8
SMART CHARGING RELATED SERVICES ...................................................................... 137
CHARGING STATION AVAILABILITY SERVICE................................................................... 137
ROUTE TO CHARGING STATION SERVICE ....................................................................... 138
CHARGING STATION RESERVATION SERVICE ................................................................. 138
CHARGING STATION ENFORCEMENT SERVICE ............................................................... 139
© 2016
113
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
D2.2.A ANNEX
Template for Service Descriptions
The following template is used for the high-level description of services addressed in the use
cases. For the deliverable D2.2.a, services are only mentioned with a basic (high level) description. In further stages of the project (pilot specification, further iterations), these services can be modified, added, removed and/or specified in detail.
SERVICE NAME
Name of the service
Description
a high level description of the service
CONSUMER
The service acts as a consumer: What data does the service consume to
offer its functionalities? (e.g. Smart Objects involved)
Inputs
<name>: <Type>
PROVIDERS
The service acts as a provider for other services / apps: What are the
input- and output data of the service within the use cases mentioned?
Use Case 1 (Use Case
that addresses the
service)
Input
Use Case 2
Input
Description
Output
Output
…
Input
Output
COMMENTS (optional)
If any comment should be added
© 2016
114
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
1
D2.2.A ANNEX
Smart Parking Related Services
SERVICE NAME
Parking Availability Service
Description
This service will provide information about available parking spots in
an area based on user location or route target.
CONSUMER
id
Parking Spot ID
timestamp
timestamp of last occupancy state change
occupancy state
Actual state of parking spot
X,Y
Coordinates, Location position of parking spot
Rectangle
boundaries
size of parking spot
Input
Coordinates: X; Y: (Double): center position,
around which free parking spots shall be provided.
Range (int): Radius around center position (Buffer
for Search)
Optional: Car Size (double): Size of Car, for which
a fitting free parking spot shall be provided.
Output
position of nearest free parking spot to current /
target location
Input
Rectangle (X-Y): (Double-Array): Area that shall
be observed
Output
areas in which high amounts of possible parking
violations occur
Input
Coordinates: X; Y: (Double): actual position
Output
area near actual position, in which high amounts
of possible parking violations occur
PROVIDERS
[SP-NG-01] (Find free Parking Spot)
[SP-NG-11] (Monitor Parking Spot Area From Desk)
[SP-NG-12] (Monitor Parking Spot Area On Street)
© 2016
115
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
D2.2.A ANNEX
SERVICE NAME
Route to Parking Spot Service
Description
This service returns a route from a starting point A to a destination B, taking
the availability of a free parking spot at the destination location into account.
CONSUMER
Inputs
Router
Router for Cars
Parking Spot Availabilities
Result of Parking Spot availability service
Input
Route Info’s: Route Start and Destination (Coordinates)
Car Size: Size of Car to propose a parking spot
bigger than car
Time: planned time for ride
Output
route from start to parking spot near destination
and walk to destination
PROVIDERS
[SC-NG-05] (Route
to parking spot)
SERVICE NAME
Reservation of parking spot service
Description
This service will support reserving a parking spot.
CONSUMER
Inputs
<name>: <Type>
description
Parking spots : JSON
Id of the parking spot the user want to reserve
Live parking spot availability :
JSON
Information about the availability of parking
spots
User ID + identity provider :
Unknown
User ID used to allow the user to park, but also
used to link payment
Input
Reservation request of parking spot [spotID,
timeframe, userID]
Output
Availability and cost
PROVIDERS
[SP-NG-04]
COMMENTS
(optional)
This is a very simple description of this service - it is not yet known if the capabilities to perform parking spot reservation will be in place in pilot.
© 2016
116
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
D2.2.A ANNEX
SERVICE NAME
Parking predictive service
Description
This service will give a prediction of the availability of parking lots, based on
information about parking lots, such as current and historical availability, together with information about people density in area of parking lots.
CONSUMER
Inputs
People density information :
JSON (specific format to be
defined/proposed)
Information about current number of people in an area. This is fetched from the service “People density estimation in area”
Live parking lot availability :
JSON
Information about current availability of
parking spots
Historical parking lot availability : JSON
Historical information about availability of
parking spots
Area : JSON
A square area defined by north east/south
west corners.
Area : JSON
A square area defined by north east/south
west corners.
Input
Area (unidentified parking location) +
timeframe
Output
Probability of finding a free parking spot
within the area in the timeframe
Input
Parking spot (identified parking location) +
timeframe
Output
Probability of this parking spot being available within the timeframe
PROVIDERS
[SP-NG-02]
Use Case 2
[SP-NG-02]
© 2016
117
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
D2.2.A ANNEX
SERVICE NAME
Check-In / Check-Out Payment Service
Description
Check-In / Check-Out Payment Service will manage new arrivals and departures in a parking area. In addition payment procedure will be handled.
CONSUMER
Inputs
-
PROVIDERS
[SP-BCN-05]
Check-in
[SP-BCN-06]
Check-out
[SP-BCN-07]
[SP-NG-06]
Pay for Stay
Input
Vehicle identifier plate
Location or Parking spot id
Time Stamp
Parking Type
Fare
Output
Token
Parking spot id (optional)
Fare confirmation
Max duration allowed
Input
Token
Time Stamp
Output
Duration
Input
Token
Duration
Parking Type
Fare
Output
Parking spot id
Vehicle identifier plate
Time Stamp in
Time Stamp out
Duration
Amount
Check-out Fare
Updated Token
© 2016
118
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
D2.2.A ANNEX
SERVICE NAME
Parking Enforcement Service
Description
The Parking Enforcement Service aggregates data of parking spot detectors in a
way that supports enforcement officers in becoming more efficient in their
work by giving recommendations for observing specific areas. Therefore, the
Service offers information about areas with high amounts of current violations
(e. g. second lane parking, parking in intersections etc.) or high probability of
violations (e. g. high current parking pressure).
CONSUMER
Inputs
Occupancies Parking Spot Detector Data (Occupancies)
Violations
Parking Spot Enforcement Data (Violations)
Background
Map
Map Data (Geospatial References, Background-Maps)
PROVIDERS
[SP-NG-11] (Mon- Input
itor Parking Spots Output
from Desk)
parking detector data
[SP-NG-12] (Mon- Input
itor Parking Spots Output
on Street)
Parking detector data
Map / statistics showing areas of high violations (potential)
optimized for a browser.
Map / statistics showing areas of high violations (potential)
optimized for smartphones / tablets.
© 2016
119
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
2
D2.2.A ANNEX
Smart Traffic Management Related Services
SERVICE NAME
Traffic Monitoring Service
Description
Smart Traffic Monitoring service will implement data filtering, map matching
(for connected cars data) and estimate traffic variables (i.e. travel times and
speeds).
CONSUMER
Traffic sensors: Bluetooth/WIFI
hash, timestamp, signal intensity, type
(WIFI/Bluetooth)
travel times (through WS API)
Traffic sensors: magnetometers, loop detectors
Traffic sensors: cameras
vehicle count, instantaneous speed
Smart Cars data
geo position, speed, acceleration
[STM-BCN-01]
[STM-PIE-01]
Get Traffic Information
Input
Area specification (i.e. coordinates + radius)
Output
Set of Travel Time, Speed and other information
at link level (where available)
[STM-BCN-02]
[STM-PIE-02]
Monitor Traffic
Alarms
Input
Set of links
Warning KPI’s threshold
Alarm Monitoring Interval
Output
Push Notification of threshold reached for specific KPI
[STM-BCN-03]
Get Travel Times
between 2
points
Input
Predefined Origin-Destination pair
Output
Estimation of Travel Time
[GRP-BCN-01]
[GRP-PIE-01]
Find Green
Routes
Input
Area specification or set of links
Output
Set of Travel Time, Speed and other information
at link level (where available)
Inputs
vehicle count
PROVIDERS
© 2016
120
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
D2.2.A ANNEX
SERVICE NAME
Environment Monitoring Service
Description
This service collects environmental data from sensors spread on the territory. It may have the ability to issue alarms in the event preset thresholds are
crossed.
CONSUMER
Inputs
Air quality station: CO
Calibrated reading of CO in open air, most interesting in areas with traffic congestion.
Air quality station: CO2
Calibrated reading of CO2 in open air, no more
than one sensor per City.
Air quality station:PMx
Calibrated reading of PMx in open air in selected
locations.
Air quality station:NO2
Calibrated reading of NO2 in open air, most interesting in areas with no traffic congestion.
Air quality station:O3
Calibrated reading of O3 in open air, in residential or green areas; one per City.
Air quality station: T
Calibrated reading of Temperature in open air,
in all monitored spots.
Air quality station: H
Calibrated reading of Humidity in open air, in all
monitored spots.
Air quality station: other
Reading of additional sensors for local pollutants, i.e. from industrial plants (examples SO2,
Pb, HC, VOC).
Air quality station: position
Noise City Sensor: noise
Geographical position (latitude, longitude)
Noise City Sensor: position
Smart Connected Car: CO
Geographical position (latitude, longitude)
Smart Connected Car:
NO2
Smart Connected Car:
speed
Smart Connected Car:
acceleration
Smart Connected Car:
position
Calibrated reading of NO2
Input
Area specification (i.e. coordinate + radius)
Output
Suggested route based on current readings of
sensors spread over the requested area.
Noise (dBA)
Calibrated reading of CO in open air,
Speed of the connected car
Acceleration of the connected car
Geographical position (latitude, longitude)
PROVIDERS
[GRP-BCN-01]
[GRP-PIE-01]
Find Green Routes
[HBN-PIE-01]
Find Healthier
Route
© 2016
121
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
D2.2.A ANNEX
via Routing Service
[STM-BCN-04]
[STM-PIE-04]
Monitor Environment Alarms
Input
Area specification (i.e. coordinate + radius)
Output
The service returns alerts when combinations of
real time sensors readings are over the limit
values established by the Municipal Authority
[STM-PIE-03]
Get Air Quality
Conditions, via
Browser
Input
Area specification (i.e. coordinate + radius)
Output
Current readings of sensors spread over the
requested area.
SERVICE NAME
Traffic Recommendations Management Service
Description
Traffic Recommendations Management Service will provide active recommendations about traffic/environment. These recommendations are generated in the control center.
CONSUMER
Inputs
PROVIDERS
Input
Area specification or set of links
Recommendation (i.e. avoid area, speed limitation…)
Recommendation validity period
Output
-
[STM-BCN-06]
Get Environment
Recommendations
Input
Area specification or set of links
Output
Active recommendations.
[GRP-BCN-01]
[GRP-PIE-01]
Find Green Routes
Input
Area specification or set of links
Output
Active recommendations.
[STM-BCN-05]
Set Environment
Recommendations
© 2016
122
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
D2.2.A ANNEX
SERVICE NAME
Analytic Services for Traffic Management - O/D Table
Description
This service will provide Origin/Destination matrix, quantifying the number of
people moving between two points of a given roads network or two areas of
a given geographical area.
CONSUMER
Inputs
Mobile
network
traffic data
Mobile network traffic data, containing timestamp, network
event type (SMS, call setup, location update, etc.) and location
information are processed in order to build traces of people
journeys.
Journeys are then processed in order to derive statistics about
origin and destination of the people journeys and the total
number of trips.
Input
Trips origin and destination specification (i.e. coordinates and
radius or areas selection in a list of areas).
Trips Origin and Destination can be specified through the
selection on a map of a pair of Points of interest or a pair
of areas.
Estimated number of trips.
The select POIs or areas can be shown on a map with the estimated number of trips.
PROVIDERS
STM-PIE-07
O/D Matrices Generation
Output
SERVICE NAME
Analytic Services for Traffic Management - People density at POI
Description
This service will provide data for people density at a given Point of Interest at
the moment of the service request
CONSUMER
Inputs
Mobile
network
traffic data
Mobile network traffic data, containing timestamp, network
event type (SMS, call setup, location update etc.) and location
information are processed in order to build metrics regarding
people presence on every location of the monitored area.
That metrics is then elaborated in order to derive statistics
about the number of people at the given POI.
PROVIDERS
STM-PIE-07
O/D Matrices Generation
Input
POI selection on a map or through specification of POI coordinates and radius
Output
The estimated number of people
The number of people and the selected POI can be shown on
the map of the monitored area
© 2016
123
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
D2.2.A ANNEX
SERVICE NAME
Analytic Services for Traffic Management -Historical People density at POI
Description
The service will provide people density at a given Point of Interest and at a
given day/time
CONSUMER
Inputs
People
Density at
POI
People presence at POI are stored in order to enable statistical
analysis about people presence at POIs
Input
POI specification (i.e. coordinate + radius or areas selection in a
list of POIs) together with day/time.
Output
Estimated number of people at the given day/timing at the selected POI.
The select POI can be shown on the map with the estimated
number of people
PROVIDERS
STM-PIE-07
O/D Matrices Generation
SERVICE NAME
Analytic Services for Traffic Management - Road Traffic Information
Description
Vehicular traffic index per road segment.
CONSUMER
Inputs
Mobile
network
traffic data
Mobile network traffic data, containing timestamp, network
event type (SMS, call setup, location update etc.) and location
information are processed in order to build traces of people
journeys.
Traces are processed to derive vehicular traffic forecast.
Input
Road segment specification through the selection on a list of
road segments.
Output
Traffic index representing the forecasted vehicular road traffic.
Traffic index is expressed on 4 levels according to DATEX II Data
Model (Free Flow, Heavy, Congested, Impossible)
PROVIDERS
STM-PIE-09
Route Assignment
© 2016
124
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
D2.2.A ANNEX
SERVICE NAME
Analytic Services for Traffic Management - Area Traffic Information
Description
Vehicular traffic index per geographical area
CONSUMER
Inputs
Mobile
network
traffic data
Mobile network traffic data, containing timestamp, network
event type (SMS, call setup, location update etc.) and location
information are processed in order to build traces of people
journeys.
Traces are processed to derive vehicular traffic forecast.
Input
Geographical area specification through a selection in a list of
areas.
Output
Traffic index representing the forecasted vehicular traffic in the
given area.
Traffic index is expressed on 4 level according to DATEX II Data
Model (Free Flow, Heavy, Congested, Impossible)
PROVIDERS
STM-PIE-09
Route Assignment
SERVICE NAME
Analytic Services for Traffic Management - Mobility Patterns
Description
Mobility Patterns describing common behaviors referring to mobility activities
CONSUMER
Inputs
Data derived
from Mobile
network
traffic data
O/D tables are processed in order to provide statistical analysis
about common mobility behaviors.
Examples are journeys conducted where, when, for how long,
using what transport mode and which route.
Input
Trips origin and destination specification (i.e. coordinate +
radius or areas selection in a list of areas).
Mobility patters selection in a list of patterns (main mobility
flow in a day, commuting flows, inbound/outbound flows etc.)
Output
The statistical metrics for the requested mobility pattern
PROVIDERS
STM-PIE-08
Transport Modes
© 2016
125
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
SERVICE NAME
Description
D2.2.A ANNEX
Analytic Services for Traffic Management - Cellular Data Cross Correlation
with external data sources
Cross correlation between cellular data and external data sources to provide
forecast for the phenomena measured by the external data source.
CONSUMER
Inputs
Mobile
network
traffic data
External
data provided to
cross correlate
Mobile network traffic data, containing timestamp, network
event type (SMS, call setup, location update etc.) and location
information are processed in order to derive mobility metrics,
such as traces of people journeys or people presence at specific
location.
Correlation models are executed in order to derive forecast for
the external data source based on metrics derived by Mobile
Network traffic data.
Example of external data can be: noise, air pollution and waste.
PROVIDERS
Input
Area and day/time specification
Output
The forecast for the external data source
© 2016
126
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
3
D2.2.A ANNEX
Public Transport Optimization Related Service
SERVICE NAME
People density estimation on bus service
Description
Service that gives an estimate of the number of people currently on the bus,
based on information about Wi-Fi probes emitted by users devices, collected
by sensors on buses.
CONSUMER
Wi-Fi probe samples :
JSON (specific format to
be defined/proposed)
Containing Wi-Fi probe information such as device
ID, timestamp, GPS, sensor ID. This is fetched from
an IoT platform.
Sensor ID : JSON
The ID of the sensor of interest
Use Case 1
[PTO-NG-01]
[PTO-NG-02]
[PTO-NG-09]
Input
Sensor ID
Output
Current estimated number of people on bus [count,
timestamp, GPS]
Use Case 2
[PTO-NG-02]
[PTO-NG-09]
Input
Sensor ID + time frame
Output
Number of people on bus within time frame [count,
timestamp, GPS]
Use Case 3
Input
Query sensor IDs
Output
List of sensor IDs [ids]
Use Case 4
[PTO-NG-02]
Input
Sensor ID + subscription
Output
Push number of people on bus continuously [count,
timestamp, GPS]
COMMENTS (optional)
Possibly the sensor ID could be interchanged with a bus ID, perhaps with bus
line ID, such that each sensor is mapped to a bus line.
Inputs
PROVIDERS
© 2016
127
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
D2.2.A ANNEX
SERVICE NAME
People density estimation in area service
Description
Service that gives an estimate of the number of people currently in an area,
based on information about Wi-Fi probes emitted by users devices, collected by
sensors on buses.
CONSUMER
Wi-Fi probe samples :
JSON (specific format to
be defined/proposed)
Containing Wi-Fi probe information such as device
ID, timestamp, GPS, sensor ID. This is fetched from
an IoT platform.
Sensor ID : JSON
The ID of the sensor of interest
Area : JSON
A square area defined by north east/south west
corners.
Use Case 1
[PTO-NG-01]
[PTO-NG-07]
Input
Area
Output
Current estimated number of people in area [count,
timestamp]
Use Case 2
[PTO-NG-07]
Input
Area + timeframe
Output
Number of people in area within timeframe [counts,
timestamps]
Use Case 3
Input
Area + subscription
Output
Push number of people in area continuously [count,
timestamp]
Use Case 4
[PTO-NG-08]
Input
Area + timeframe
Output
Movement vectors of people in area [vectors]
SERVICE NAME
Live bus position service
Description
This service gives live information about the location of buses.
Inputs
PROVIDERS
CONSUMER
Live GPS locations of sensors :
Information about where a sensor currently is located. This is fetched from an IoT platform.
Bus-sensor mapping :
JSON
Information about which sensor is placed on which
bus. This is fetched from an IoT platform.
Bus-line ID : JSON
Defining the bus line of interest, i.e. both defining
the city and the line number.
Use Case 1
[PTO-NG-06]
Input
Bus line ID + timeframe
Output
Current location of buses on that line within
timeframe
Use Case 2
Input
Query bus lines
Output
List of bus lines
Inputs
PROVIDERS
© 2016
128
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
4
D2.2.A ANNEX
Healthy Bike Navigation Related Services
See “Routing Service” on page 131.
© 2016
129
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
5
D2.2.A ANNEX
Smart Bike Sharing Related Services
SERVICE NAME
Dock and Bikes Availability Service
Description
For each Bike Sharing Station, in the selected area, the service returns the actual
number of: total docks, available docks and available bikes.
CONSUMER
Inputs
Bike Sharing
give information about available docks and bikes
Input
Area and radius (desired destination and tolerance distance to locate a bike or a dock)
Output
Show xx free docks and yy free bikes in bike sharing stations within the selected area and in range
grouped by bike stations
PROVIDERS
SBS-PIE-01
SERVICE NAME
Dock and Bike Estimation Service
Description
This service will give a prediction of the availability of bikes and docks, based
on information about docks, such as current and historical availability, together
with information about people density in area around bike sharing station and
live bicycle position information.
CONSUMER
Inputs
People density estimation from Mobile Analytics: JSON
Bike sharing station
status (total docks,
docks statuses) : JSON
Spot and range : JSON
Read from the Vodafone platform
Bike location : JSON
Read from SDP platform, real-time location of a
bike. The position could be sent by the rider's app or
other IoT device
Input
Bike sharing station location + now/future datetime
for prediction
Output
Number of estimated bikes at the given location at
the date/time of interest
Input
Bike sharing station location + now/future datetime
for prediction
Output
Number of estimated available docks at the given
location at the date/time of interest
Input
Bikes live location, bike sharing station location
Output
Estimated time of having a bike available at the chosen sharing station
Fetched from an IoT platform such as SDP
A round area defined by a point and a range
PROVIDERS
[SBS-PIE-02]
[SBS-PIE-03]
[SBS-PIE-04]
© 2016
130
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
6
D2.2.A ANNEX
Incentive Based Green Route Planning Related Services
SERVICE NAME
Routing Service
Description
The service returns the route to follow from point A to point B taking into account
waypoints to avoid because of traffic congestion, pollution or traffic controller
indication.
CONSUMER
Inputs
Map
Map to the world
Traffic Monitoring Service
Output of the Service
Environment Monitoring
Service
Traffic Recommendations
Management Service
Output of the Service
Input
Vehicle options [By car, by bike]
Route options [fastest, shortest, recommended,
healthier]
Waypoint [zero or more waypoints]
Origin (x,y) [origin of the trip]
Destination (x,y) destination of the trip]
Output
Route from Origin to Destination with combined
parameters
Output of the Service
PROVIDERS
[SP-all-04]
[HBN-PIE-01]
[GRP-all-01]
© 2016
131
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
D2.2.A ANNEX
SERVICE NAME
Incentive Management Service
Description
This service handles the collection of points for participating users that follow
green recommendations.
CONSUMER
Inputs
Traffic Recommendations Management Service
Output of the Service
Input
Username : OpenID
Incentive Program Name : text (ex.
Barcelona, Biella, Vercelli)
Suggested route: GeoJSON
Followed route: GeoJSON
Output
User score and ranking
PROVIDERS
[GRP-BCN-03]
[GRP-PIE-03]
Follow Green Recommendations
COMMENTS (optional)
This service receives both the suggested route (computed by the Routing
Service) and the followed route (output of the end-user App), applies a
matching algorithm and computes a compliance percentage that is translated
into collected points. 10% compliance equals to 1 point, 20% compliance
equals to 2 points, in increments of 10%/1 point.
For privacy reasons the service keeps no record of the route followed once
the compliance level has been computed.
© 2016
132
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
7
D2.2.A ANNEX
Multimodal Route Optimization Related Services
SERVICE NAME
Personalization Service
Description
The Personalization Service allows users to store their contact data, preferences and behavioral data as well as preferred routes on a server for being
actively informed about changes in traffic situations.
CONSUMER
Inputs
Contact Data
Ways the user can be / wants to be contacted in case of recommendations for changes in traffic behavior.
Routes and
Traffic
Modes
Preferences
for Traffic
Typical Routes / preselected alternative routes for the user.
Input
User Routes
Output
Input
User Profile and Preferences
Traffic Preferences for alternative routes (e.g. public transport
yearly tickets, memberships in car sharing offers)
PROVIDERS
[MRO-NG-01]
(Initial Routing)
[MRO-NG-02]
(Save Route)
Output
[MRO-NG03/04/05] (Monitoring & Detour)
Input
[MRO-NG-09]
(Inform Commuter)
Input
Output
Output
User Profile and Preferences
Contact Ways
© 2016
133
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
D2.2.A ANNEX
SERVICE NAME
Multimodal Routing Service (for corridor B-WOB)
Description
For a given Start-Destination Combination and time, the Service returns the best travelling options for different transport modes.
CONSUMER
Inputs
Modal Routers
Routing Services for Car, Train, Bike and foot.
Actual Traffic
Situation
PROVIDERS
[MRO-NG-01] (Initial
Routing Start to Destination)
[MRO-NG-05] (Detour)
Input
Start of Route (coordinates, current location or
chosen location)
End of Route (coordinates, target location)
Time (now or later)
Set of Preferences (e.g. transport modes, car availability, memberships, PT-Tickets)
Output
best routes for Start-Destination relations based on
preference
Input
Start of Route (coordinates, current location or
chosen location)
End of Route (coordinates, target location)
Time
Set of Preferences (e.g. transport modes, car availability, memberships, PT-Tickets)
Output
detour recommendation based on actual traffic
situation
© 2016
134
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
D2.2.A ANNEX
SERVICE NAME
Route Monitoring Service
Description
The Route Monitoring service monitors the actual traffic situation on precalculated routes (Result of Multimodal Routing Service) and triggers Incident
notification service if high deviations occur (e.g. long delays).
CONSUMER
Inputs
Traffic Situation on streets
(travel times / los)
Traffic Incident messages
description
operational status messages
on public transport
PROVIDERS
[MRO-NG-03] (Monitor Highway Traffic
Situation)
Input
set of highway / street routes
thresholds for notifications
Output
Notification in Case of Delay higher than
threshold
[MRO-NG-04] (Monitor Rail Traffic Situation)
Input
set of public transport routes (lines, carriers,
times)
thresholds for notifications
Output
Notification in case of delay higher than
threshold or changes or service interruptions
SERVICE NAME
Car Sharing Reservation Service
Description
This service allows end-users to find and directly reserve a car sharing
car for his route.
CONSUMER
Inputs
car sharing car
availabilities
car sharing cars available for reservation (provided by car sharing providers)
Input
Reservation Request of user
Output
Reservation Confirmation to user
PROVIDERS
[MRO-NG-07] (Reserve
alternative vehicle)
© 2016
135
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
D2.2.A ANNEX
SERVICE NAME
Incident Notification Service
Description
The incident notification service informs an end user (commuter or traffic participant) about disruptions, service delays or congestions on his
predefined routes.
CONSUMER
Inputs
Route ID (int)
unique identifier of a route for that an information is available
Actual State ID (int)
status of route
Actual State Information
machine readable information about kind of state
and next actions
Timestamp
(Date/Time)
Message (string)
date of last state change
Detour Information
(optional)
User Readable information about a possible detour
Input
incident on route
Output
Push-information to end-user on his preferred
information channel (e.g. mail, app notification,
SMS...)
user readable message about the actual state of
his route
PROVIDERS
[MRO-NG-09] (Inform
Commuter About Deviation)
SERVICE NAME
Detour / Mode Shift Recommendation Service
Description
This service is informed about delays on routes and uses the intermodal router
to propose a different travel option.
CONSUMER
Inputs
Route ID
Modal Route that is affected by congestion / incident
Input
Modal Route Information
Output
Recommendation for detour on current mode (e.g. detour on
street)
Recommendation for modal shift (e.g. using car sharing car instead
of train)
PROVIDERS
[MRO-NG-05]
(Detour)
© 2016
136
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
8
D2.2.A ANNEX
Smart Charging Related Services
SERVICE NAME
Charging Station Availability Service
Description
This service will provide information about available charging stations in an area based on user location or route target.
CONSUMER
id
Charging station ID
timestamp
timestamp of last occupancy state change
equipment
Technical equipment of charging station (e.g. plug,
voltage etc.)
occupancy
state
X,Y
Actual state of charging station
Input
Coordinates: X; Y: (Double): center position, around
which free charging stations shall be provided.
Range (int): Radius around center position (Buffer for
Search)
Optional: technical equipment needed (e.g. voltage,
plug...)
Output
position of nearest free charging station spot to current / target location
Input
Rectangle (X-Y): (Double-Array): Area that shall be
observed
Output
areas in which high amounts of possible charging
station parking violations occur
Input
Coordinates: X; Y: (Double): actual position
Output
area near actual position, in which high amounts of
possible charging station parking violations occur
Coordinates, Location of charging station
PROVIDERS
[SC-NG-01] (Find free
Charging Station)
[SC-NG-11] (Monitor Charging Stations From Desk)
[SC-NG-12] (Monitor Charging Stations On Street)
© 2016
137
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
D2.2.A ANNEX
SERVICE NAME
Route to Charging Station Service
Description
This service returns a route from a starting point A to a destination B, taking
the availability of a free charging station at the destination location into account.
CONSUMER
Inputs
Router
Router for Cars
Charging Station Availabilities
Result of Charging station availability service
Input
Route Info’s: Route Start and Destination (Coordinates)
CS-Requirements: Technical Equipment needed at
Charging station
Time: planned time for ride
Output
route from start to charging point near destination and walk to destination
PROVIDERS
[SC-NG-04] (Route
to charging station)
SERVICE NAME
Charging Station Reservation Service
Description
This service allows end-users to directly reserve a Charging Station in
private area for his route.
CONSUMER
Inputs
Charging Station
Availabilities
Charging Stations available for reservation (provided by Charging Station Operators)
Input
Reservation Request of user
Output
Reservation Confirmation to user
PROVIDERS
[SC-NG-03] (Reserve
Charging Station)
© 2016
138
PART 3: HIGH LEVEL SERVICE DESCRIPTIONS
D2.2.A ANNEX
SERVICE NAME
Charging Station Enforcement Service
Description
The Charging Enforcement Service combines data of parking spot detectors with
those of charging stations and aggregates them in a way that supports enforcement officers in becoming more efficient in their work by giving recommendations for observing specific areas. Therefore, the Service offers information
about areas with high amounts or high potential of current violations (e.g. combustion vehicles parking on charging station attached parking spots or electric
cars parking too long on charging station attached parking spots).
CONSUMER
Charging Occupancies
Parking Occupancies
Availability of charging stations
Violations
Parking Spot Enforcement Data (Violations)
Background Map
Map Data (Geospatial References, Background-Maps)
[SP-NG-11]
(Monitor Parking Spots from
Desk)
Input
parking detector data, charging station data
Output
Map / statistics showing areas of high violations (potential) optimized for a browser.
[SP-NG-12]
(Monitor Parking Spots on
Street)
Input
parking detector data, charging station data
Output
Map / statistics showing areas of high violations (potential) optimized for smartphones / tablets.
Inputs
Parking Spot Detector Data (Occupancies)
PROVIDERS
© 2016
139