Contract Delivery Date Actual Delivery Date Deliverable Type

1 Introduction

This document contains the description of the use cases that will support the prototyping and evaluation of the generic adaptive middleware for behavior-driven autonomous services developed in the project. It also provides a first description of the building blocks that will further analyzed during the architecture design. In the following, we first detail the purpose, the scope and structure of the document before we describe the scenarios and use cases.

1.1 Purpose

The purpose of this document is to describe the envisioned applications resulting from this project, and the context where these applications will be used and tested. The goal is to summarize the expectations of the end-users (software developers, public transport operators and citizens) with regards to GAMBAS in a document.

Moreover, the document serves as the common tool to promote the negotiation and discussion within the consortium to set the limits of the research and the final demonstrations at the end of the project. This way, the scenarios proposed in this deliverable follow a twofold objective: guarantee a realistic demonstration of a smart city framework – specifically for mobility and environmental applications – and explore innovative new features and added value services raised from the availability of open and private data in a secure manner.

The scenarios will serve as test beds for the applications and pieces of software tackled in GAMBAS: a data acquisition framework, a privacy middleware, a semantic platform, an intent-aware end-user mobile application, an environmental monitoring and information service and an improved exploitation support system for the bus transport network in Madrid.

Last but not least, the document introduces the building blocks that will be used within the project. They have been drafted based on the specifications derived from the use cases and scenario definitions, as well as the list of requirements in [D11].

1.2 Scope

This deliverable is part of the main results of the requirement analysis phase of the project (WP1), jointly with D1.1 [D11]. Both documents are issued together and have been developed simultaneously. Thus, mutual dependencies exist across the documents. The editors have tried to keep this deliverable self-contained, minimizing the need of reading both documents by repeating part of the information provided in [D11]. However, it is highly recommended to read both deliverables following their natural order – i.e. D1.1 first and later D1.2. In this way, the reader will understand the global research framework defined in this first phase of the project.

All partners of the GAMBAS consortium have participated in the specification of use cases and scenarios. Hence, the non-technical specifications provided by the main end users (EMT), have been used by the technology providers to understand the system requirements and progress towards the design documents that will be developed next in the project. Thus, the top-down approach followed in this deliverable complements the mainly bottom-up approach followed in D1.1.

The descriptions in this document are not part of the final design specifications to be provided in the research and development phase of the project (WP2, WP3, WP4 and WP5), but they define a set of use cases and scenarios specifications to set the grounds for the upcoming work. In this context, the The descriptions in this document are not part of the final design specifications to be provided in the research and development phase of the project (WP2, WP3, WP4 and WP5), but they define a set of use cases and scenarios specifications to set the grounds for the upcoming work. In this context, the

1.3 Structure

The document is structured around four main sections describing the motivating scenarios and project vision, the basic building-blocks to achieve this vision, the formal specification of use cases to describe the functionalities that are expected by the end of the project, and a coverage analysis and selection of the most relevant – and feasible – use cases.

This prioritization is critical in order to establish the development plan for the upcoming work packages, and it represents the first description – even at a preliminary stage – of the tests that will

be performed to validate the results of the project.

2 Motivating Scenarios

In the following, the GAMBAS vision is outlined and a number of scenarios are described in order to clarify the vision. Based on the scenarios, a number of strong concepts are we derived to underline the novelty of the approach.

2.1 Vision

The GAMBAS project fits within the framework of smart cities as a cloud of intelligent digital services which provides adaptive and predictive information to citizens and distributed embedded terminals. The project, from the point of view of innovation and research, tries to make a contribution to the existing takes on smart cities by:

A. Processing information dynamically depending on the behavior of citizens in cities.

B. Considering the citizens not only as consumers of digital services, but also as sources of information providing feedback to the city.

The following sections present the scenarios that motivated the project and extract the key concepts that will be mapped into the building blocks and architecture enabling the GAMBAS approach.

2.1.1 Mobility Scenario: “John arrives to town”

John has just arrived to a new city. At the airport he receives a message on his mobile phone by Bluetooth broadcast welcoming him to the city and inviting him to download an application on his smart phone in order to make his life in the city easier and to make his visit more enjoyable.

He follows the link proposed by the welcome message and downloads the application. When booting the application for the first time, he is requested to provide some data that does not affect his privacy. From that moment on, the application begins to capture the context related to John ’s interests including the change of positions, used transport modes, visited shops, etc.

The interface requests John to select which type of information he is interested in. John can choose from different sources of information and services. For this short visit to the city, John selects the mobility, events and shopping layers. The selection of “events” invites John to refine his selection and choose among different kind of events: sports, theatre, exhibitions, conferences, etc. John selects sports and theatre.

The interface also suggests John to connect his smart phone application with social networks such as FourSquare, Facebook and Twitter. John selects Foursquare in order to publish his “check-in” events and share them with his friends in the city.

As it is the first time John visits the city, and he has just downloaded the application, the application is not able to predict the targeted destination of John. His city behavior profile has been just created and the phone's calendar is empty.

Thus, the application asks John “what do you want to do?” John responds via voice "I want to go to the Hotel Astoria". The smart interface of the application

detects and recognizes the semantics of the phrase "go to" "hotel astoria" and suggests this destination. John confirms this selection with a simple gesture on his smart phone.

The application then shows John the route through public transport means to reach his destination. John begins his trip first by metro and then continues by bus. The application on his phone is able to detect at any time where John is and alerts John shortly before he has to leave the metro. Thereby, it notifies him about which bus to take next.

If he decides to leave the recommended route, he can do it at any point and at any time. If he decides to go for a walk in the city he can leave the route and get updated route recommendations. At any point, he can look up information on the bus stops and metro stations or other points of interest (POI) making use of speech recognition combined with semantic services.

During the journey the application informs John of the sport and theater events taking place in the next days in the city.

When he is close to his destination and since it is already lunch time, his smart phone suggests three restaurants nearby his hotel. At any point during his visit to the city, John can identify locations with

a voice tag. At the location of the selected restaurant he can use the voice recognition system to tag the location “Luigi’s restaurant” or “Good Pasta”. Later one, the voice recognition will be able to use this information to lead John back to the restaurant.

After lunch the application suggests buying in Cortefiel next to his hotel that has a 2 x 1 offer in spring shirts.

Once arrived at his destination the application detects his "check-in" and suggests John to publish the event on his enabled social networks. John accepts the suggestion and according to his settings, his location is published in Foursquare. Once the goal is achieved – i.e. arrival to destination - the application returns to its initial state, “What do you want to do”.

This time, John ignores his smart phone however, while John is in the city, the application keeps analyzing his behavior and suggesting information and services based on his position and preferences.

The application can notify John about shopping deals depending on his position and the proximity of the shops. Thus, the interaction with the end-user becomes more efficient and the GAMBAS framework is capable to filter the offers, resulting in a much less annoying solution (AdGeosense).

2.1.2 Environmental Scenario: “Paul goes jogging”

Paul is a regular user of the smart city application on his mobile phone. He uses it regularly to find out the best options to get around in the city. For this, he is always subscribed to the mobility layer.

Today, he has decided to do some sport around the city, and his friend Ringo has explained him how to make use of the smart city application to obtain a jogging route through the less polluted areas of the city (CO2 levels). He indicates the number of kilometers he wants to run, and for how long, he also specifies that if possible he would like to run with some friend.

As a result, the smart city application offers him a route with Ringo. Paul observes that in order to have a reasonable route, the mobile application is proposing to take first a bus to the starting point of his jogging route.

At the same time Ringo, who was already planning to go jogging, receives an alert asking him if he wants to share a route with Paul. He accepts and both friends receive a confirmation on the appointment in their agendas.

Ringo is not as concerned when it comes to environmental issues as Paul, so he does not use the public transport. Instead its smart city application proposes him a route by car through an urban tolling area. He is though, quite concerned about costs, and by default he is subscribed to the mobility layer offering him a car pooling services. The urban tolling in the city depends on a number of factors such as type of vehicle used, number of passengers in the car, and level of pollution in the city. Ringo receives a proposal from the application to share the trip with his friend George.

When activating the environmental layer on his mobile phone – in order to access the levels of CO2 in the city – Paul has accepted to join the group of users collaborating with the municipality to study the noise levels in the city. Without any further intervention from his side, its mobile phone records and process measurements of noise level each time Paul is outdoors and changes his position. At the end of the day, Paul can access the city pollution map application and check the noise levels in the route he has being following, including the jogging activity. Moreover, he obtains his environmental footprint due to the trip on public bus.

2.1.3 Shopping Scenario: “Yoko goes shopping”

Yoko has been using the smart city application on her smart phone for several weeks. Her mobile phone is now capable to predict that Yoko is going ot the office every day, from Monday to Friday at 7:00am. The application suggest Yoko a route to the office, she confirms it while having breakfast. Her smartphone responds presenting the following information: time of departure of the bus that Yoko should take, estimated time of arrival (ETA), route, weather conditions, pollen and CO2 levels of locations on her route. Since Yoko is allergic, she requests a new route avoiding the areas of high concentrations of pollen. The application notifies Yoko when to leave the house considering that if she misses the first option – e.g. the bus leaving in five minutes – she would be late to work since the next bus will leave in 20 minutes.

Today is Friday and she decides to go "shopping" downtown when she concludes her working day at noon. Yoko has actually no particular interest in buying anything, she just wants to walk through the city, take a snack and relax whilst visiting some of her most preferred shops.

Yoko finishes at noon as planned and goes downtown, she has no hurry, so she decides to activate her smart city application and look for suggestions. When she leaves the bus, she checks the application and selects the shopping layer. She responds to some selection menus from the application to refine its shopping layer settings with further information. She begins to walk through the shopping streets of downtown. While she spends a nice time checking the shop windows, the application searches in the city for offers matching Yoko ’s interests, and whiles she is walking, the application informs her about those offers that may be relevant to her and that are in her proximity.

Yoko met John the other day. John is visiting the city for a few days. Yoko, in her smart city application has established a relationship of trust with John and now that she is walking down the street, her mobile alerts her that John has just entered an Italian restaurant right around the corner.

Yoko decides to join John and have lunch with him.

2.2 Key Concepts

Analyzing the three motivating scenarios detailed in the previous section, a first set of key concepts can be detected. These concepts include

 Smart city, as a set of digital services to citizens structured through different data and service layers. The smart city must be also considered as a set of open data gateways to various systems that operate in the city and contribute to the information society through open data

interfaces.  Smart city application, as an application that must be downloaded by the citizens to their

smart phone.  Smart city layer, as the repository of data and services accessible via the GAMBAS

framework. A city could contain different layers organized by domain of application. Actually, within each of the domain of application, different concurrent service providers could establish its own layer.

 AdGeosense, as various types of information that are closely linked to the position of the end-user.

 Smart agent, as a mobile application on a smart device that can support the user to capture and share relevant and important information to support the operation of the city. This agent is the one enabling the citizen to become not only a consumer of information and

services, but also a source of information for the smart city.  Voice tagging, as a way of using speech recognition to indicate any location within the city

and provide a semantic reference. Later one this location can be looked up using voice recognition. The information gathered in this way is used in the behavior profile to identify locations.

 The behavior profile concept, as a service in the cloud that stores the behavior of citizens on an anonymous basis and constitutes the citizen network layer with its own open data

interface in order to provide feedback to the framework operating the city. The behavior profile relies on behavior pattern recognition for shopping, mobility, events, etc. and real time information feeds to detect events in the city, and identify important contexts such as crowed buses or areas as well as polluted areas, etc. The behavior profile can be connected to other profiles on the Internet such as Foursquare, Facebook, etc.

 A critical functionality of the system is to suggest users the next target. The smart city application must be able to infer the next destination, or next action to be performed in the

city by the citizen. This can be achieved automatically through the use of the behavior profile or interactively via voice or text interaction with the application interface. In any case, it

involves predicting the citizen’s next action in the city such as going to work, eating, shopping, visiting a place, going to the movies, etc. Even if the user has not set a target, the

device at each change of context will attempt to infer the next target through access to the Behavior Profile.

 The behavior profile can reside locally on the smart city application or remotely in the citizen network layer. Users select the type of information they want to publish on their profile in  The behavior profile can reside locally on the smart city application or remotely in the citizen network layer. Users select the type of information they want to publish on their profile in

 The smart city application interface must be simple and without distractions. This implies a greater degree of prediction and complexity. This interface will be based primarily on speech recognition. Users select the smart city layers they want to use such as mobility, events, shopping, environment, etc. By accepting suggestions from the smart city application or by

specifying their own next target, users can trigger actions. For this, the system must be able to recognize a vocabulary and to compute predicted targets, offering the citizens the most probable targets. Once an action has been triggered, the smart city application begins to infer and present dynamic information to the citizen.

 All dynamic actions that can perform a citizen within the city involve the go to concept. It is the action of "go to" which establishes a space and time line characterizing the current and the future context of the citizen. It is this space-time frontier where the smart city interacts

dynamically with the citizen, proposing information and alerting of changes in context affecting the user. Additionally, this change of context provides valuable feedback to other smart city layers.

 The next target implies the calculation of the user’s future context and this context will be the one determining the information and the list of actions suggested to the user. As most objectives involve a "go to" trigger action, mobility will be one of the basic layers involved in

most interactions between a citizen and the smart city.

2.2.1 Semantic Layer

The smart city vision adopted by the GAMBAS project requires a semantic layer as one of the key concepts enabling a broad applicability. This is the layer that represents knowledge and provides the basis for inferring reasoning and classification of the information.

A semantic layer involves ontologies with vocabularies and semantic boundaries in a meta-language. This will be the core that will provide basis for the intelligence to the smart city as it will enable the linking and relating of the information and services of different layers.

2.2.2 Citizen Network Layer

Among the different layers acting as gateway to different sources of data and services, one of the most important ones would be the citizen network layer.

This layer will manage the behavior profile of every citizen and would provide the following services:  Registration services, citizens logs or patterns of tours.

 Time behavior patterns such as shopping, food, entertainment, etc.  Detection of incidents by agglomerations of people.  Location of citizens in whenever the citizen agrees on such tracking information, depending

on privacy criteria and trust relationship with other users.  Personal safety. Detection of strange behaviors.

The backend of this layer would constantly calculate with each update of context from a smart device and using other layers of the smart city the relevant information for citizens such as the position of friends, for example.

2.2.3 Mobility Layer

The mobility layer in the context of the GAMBAS project will provide a gateway towards the information and services provided by the EMT public transport exploitation system (PTES).

This layer could provide services such as:  Routing between different points of the city.

 Status of traffic in the city.  Estimated time of arrival (ETA) at destination in real time.  Scheduling of buses and lines.  Position of bus stops and lines.  Number of passenger per bus.

The layer will not only serve the citizens of Madrid smart city to interact with the bus public network, but also will serve EMT to interact and retrieve information from its users, following one of GAMBAS main challenges – i.e. transform users in both consumers and sources of data.

Out of the context of GAMBAS, this layer would be extended with services from other transport operators and even with services and information from the municipality – e.g. incidents in roads or information about the subway network.

2.2.4 Environmental Layer

The environmental layer will offer services informing about the environmental status of any coordinates in a smart city. This information could be related to CO2 emissions, solar radiation, noise levels, pollen concentration, etc.

This layer could be a gateway to the municipality environmental sensing systems, but in the context of GAMBAS, it could also be the data storage of environmental information collected by public transport buses equipped with environmental sensors.

Some of the buses from EMT will act as smart agents taking advantage of their mobility around the city to gather environmental data from different points in real time. It is an economic alternative to the environmental sensing stations deployed in cities nowadays. This layer could serve an environment map of the city as its main service.

3 Building Blocks

Following the motivating scenarios and the key concepts identified in the previous section, the GAMBAS consortium has tried to establish a preliminary architecture that would enable the project vision.

The building blocks identified in this document, including its interfaces and the relationship among them, must be considered as a first draft of the reference architecture to be presented in the deliverables D1.3.1 and D1.3.2. Nevertheless, this initial effort must be documented in order to provide a formal description of the uses cases that have been analyzed – see Section 4.

In order to prevent privacy issues, the citizen network layer identified as key concept was transformed into a social layer. Actually, the functionalities – service and data – contained under the citizen layer were distributed among other components hosted on the personal mobile devices – i.e. the behavior profile. This way, the private data is never stored in the cloud, preventing both, the doubts and distrust from end users as well as the legal problems of storing private personal information.

However, even with a distributed behavior profile, the social layer is still needed in order to provide the services establishing the trust relationships between users – e.g. a ‘find my friends’ query. This is

a layer that from a practical point of view was not associated with any existing service provider. In other words, and anticipating possible business models, there was no one offering or interested in offering the services associated with such a social layer –i.e. no company, at least within the consortium, would be offering services to track people and store profiles with its preferences.

Figure 1 – Original Vision

Actually, a similar problem was observed when looking at the semantic layer, a critical building block that was hard to locate on just a single host. On the one hand, all the elements participating in the GAMBAS vision – mobile devices and layers – should store semantic data and run some basic queries. On the other hand, complex operations – as continuous queries – should exclusively be supported by the information and service layers in a smart city.

With this in mind, a number of architectural building blocks were identified in order to realize the implementation of the layers required for GAMBAS:

• OQP: One-time query processor. Software component capable of running semantic queries on constrained systems (i.e. smart phones and above).

• CQP: Continuous query processor. Software component capable of running complex queries on traditional systems (i.e. PCs and above).

• SDS: Semantic data storage. Software component capable of storing semantic data on constrained systems.

• LDW: Legacy data wrapper. Software component providing a specific gateway towards

existing services and information. This component is specific for each implementation. • PRF: Privacy framework. Software component capable of granting the privacy levels

established by the end-user. It runs on constrained systems. • DQF: Data acquisition framework. Software component capable of extending smartphone

capabilities to capture data and act as a sensor for the smart city. It runs on constrained systems and it is specific of each implementation. It can also support other embedded systems for data acquisition – e.g. bus environmental sensors.

Figure 2 – Preliminary Architectural Building Blocks

When distributing the building blocks among the different key concepts, some of them disappeared into an aggregation of different components – the semantic layer – and some of them still evolved towards new building blocks. This way, the information and service layers remained as key concepts in this preliminary architecture. Particularly:

 The transport layer became the Transport System offering the gateway to the data and interfaces provided by the EMT Public Transport Exploitation System. As already explained in

Section 2, this layer could also include information from other transport modes, or even be combined with a “traffic layer” to become a “mobility system”, however, in the context of GAMBAS the scope focuses primarily on the Madrid public bus network.

 The environmental layer became the Environmental System offering the gateway to data related to environmental parameters such as CO2 emissions, noise level and pollen

concentration. In the context of the project, these are the minimum variables that will be measured through the embedded sensors in the EMT bus network. From a conceptual point of view, the layer could also host other services and act as gateway to other repositories of data – e.g. the municipality network of environmental sensing stations, or any meteorological station.

Other layers that have been analyzed, but are out of the scope of the project, are the shopping layer, the event layer and the traffic layer. Actually, any third party willing to share information and services in the GAMBAS framework could be able to do so as far as it integrates the semantic and privacy building blocks.

 A discovery service was pointed out as building block in charge of addressing the GAMBAS mobile application towards the relevant sources of information and services. Moreover this service will be responsible of receiving the manifest of functionalities and data that the rest

of layers can provide.  The citizen network was distributed among the rest of building blocks, trying to avoid the

storage of private personal data on remote. To that end, the privacy framework and the behavior profile have been defined. The first one will be in charge of negotiating the trust relationships among building blocks, whilst the second one will store the personal private data of each user within its own smartphone. This information will be later on used to establish prediction functionalities.

 The semantic layer evolved to a group of subcomponents distributed within the rest of the building blocks. In particular the semantic engine functionalities are now contented within

the one time and continuous query processors. On the other hand, a semantic storage component was defined to host the semantic data on constraint devices.

 With this new design there was still a critical functionality missing. Whenever a complex query needs to be processed – e.g. a stream query involving two different sources of data – someone needs to take responsibility over this processing effort. Thus, a generic processing

system was defined, more as a role than as new building block. Actually, any of the elements hosting one of the query processors, can act as generic processing system. However, if the party responsible for running and operating a city layer is not willing to take care of such complex queries, a new actor may appear marketing this functionality. This will be the case system was defined, more as a role than as new building block. Actually, any of the elements hosting one of the query processors, can act as generic processing system. However, if the party responsible for running and operating a city layer is not willing to take care of such complex queries, a new actor may appear marketing this functionality. This will be the case

 This approach has additional benefits, as moving the most complex stream queries to specialized hardware. Moreover, users may rely on these third party processing systems to take care of the semantic queries involving private information. In this way, they could grant certain privileges over its personal data during a specific period of time.

Figure 3 – Refined Vision and Building Blocks

4 Use Cases

The GAMBAS project is tackling two different domains of applications in order to test and validate the building blocks identified in the previous section. These two domains are obviously related and limited by the background, interests and data that each partner within the project can provide to the consortium. Both, the mobility and the environmental scenario, rely on the sensors and data acquisition capabilities deployed at the Madrid bus network operated by EMT.

These capabilities, however, will be enhanced through the use of personal mobile phones to retrieve and capture new pieces of information – e.g. desired destination, predicted destination, noise levels, event “out of bus”, etc. This will be done using the privacy framework that is developed during the project, which will guarantee at any time that users willing to share certain bits of data, will be able to decide on which private information could be published and with whom this information could be shared.

The following sections present a breakdown of the motivating scenarios related to mobility and environment described in Section 2 into a number of use cases that can be analyzed individually in order to identify involved building blocks, required pieces of data and finally allocate responsibilities among partners for the later design and development of components. The analysis must be considered as a first formal description document on the scope of the project, which will be completed with the formal definition of the project architecture in D1.3.1 and D1.3.2. Thus, the terminology used for the building blocks, could still be subject to modifications, and therefore the sequence diagrams used hereafter cannot be considered yet as a final design for implementation, but they represent a first approach to the final solution. Hence, each of the components and applications to be developed will first produce a design document based on the following use cases.

4.1 Mobility Scenario

The first scenario focuses on the functionalities of a Public Transport Exploitation System (PTES) and

a GAMBAS mobile application to take into account the information retrieved directly from the user and to offer citizens customized services – not exclusively related to mobility though – in order to enhance their trip experience.

4.1.1 Use Case 01M: Adaptive Trip Planner

Use case Id

UC01M

Title

Adaptive trip planner

Involved building blocks Discovery Service, Processing System, Transport System, Speech recognition

Involved applications

GAMBAS mobile application

Required data

Desired destination, routes, incidents, ETA

Offered services Adaptive trip plan, notifications on when to start the trip and incidents on route

Involved partners

UDE, ETRA I+D, NUIG, OU, SC, EMT

Table 1 – Adaptive Trip Planner Summary

This is the basic use case description motivated by the mobility scenario. A user wants to go from point A to point B, and arrive at a particular time. It is noteworthy mentioning that point A is captured automatically by the mobile application, and therefore evolves with the current position of This is the basic use case description motivated by the mobility scenario. A user wants to go from point A to point B, and arrive at a particular time. It is noteworthy mentioning that point A is captured automatically by the mobile application, and therefore evolves with the current position of

The target point is determined by a capture of "GoTo", which may come from a speech analysis interface asking the device for a Point of Interest (POI), from a direct selection on a map, from a predictive inference by the device after analyzing the historical behavior of the user, or from the analysis of the next appointments in its agenda.

Gambas App

Discovery Service

Processing System

Transport System Environment System

Registre data service Registre service

Select info layers

Registre data service

Discover data services for city Public data

Capture "GoTo"

announcement

Allow query location (PRF) (CQP) Stream Query Location

Location data

Stream query route from location to POI/location (CQP)

Query (CQP)

Route data

Route

Route data

Route

Update route times

capture context

Location Data

Update Query (CQP)

Route data

Route

updated

Route data

Route

Update route times

Alert init course Capture context

Location Data

Update Query (CQP)

Loop travel

Route data

Route

Alert reached destination

Figure 4 – Adaptive Trip Planner Sequence Diagram

Estimated Time of arrival (ETA) and traffic conditions may change during the day. The user will be notified by the device when to start the long route to reach its destination. Since the user origin position may change, it could trigger a new route calculation and an update on the ETA.

The device should allow a Processing System to continuously capture its position as it changes. The user should be able to establish what the minimum variation to consider a “change of position” is. When the device considers major changes of positional context, it will continuously update its The device should allow a Processing System to continuously capture its position as it changes. The user should be able to establish what the minimum variation to consider a “change of position” is. When the device considers major changes of positional context, it will continuously update its

This use case actually describes an adaptive trip planner that considers the user position – evolving on time, the actual traffic conditions and the actual times of service of the public bus transportation system.

4.1.2 Use Case 01.1M: Adaptive Intermodal Trip Planner

Use case Id

UC01.1M

Title

Adaptive intermodal trip planner

Involved building blocks Discovery Service, Processing System, Transport System A, Transport System B

Involved applications

GAMBAS mobile application

Required data

Desired destination, routes, incidents, ETA

Offered services Adaptive trip plan, notifications on when to start the trip and incidents on route

Involved partners

UDE, ETRA I+D, NUIG, OU, EMT

Table 2 – Adaptive Intermodal Trip Planner Summary

As an extension of the basic mobility use case, intermodal trips could be considered. To that end, different strategies can be defined:

a) Existence of more than one “Transport System” and a third party Processing System. This is actually the most probable scenario, closest to real life. Each of the public transport operators in a city maintains its own transport layer to publish data and services that can be used directly by the end-user or queried by a third processing system to establish and offer added value services – as intermodal plans. This is the strategy followed currently by Google. In GAMBAS, any third party could access the open data and services since we are relying on open data specification and discovery services.

b) Existence of a “Transport System” covering more than one mode of transport. In cities where the public transport operator is responsible of more than one mode of transport – e.g. Paris and Barcelona – the transportation layer could actually be more complex and natively support the queries for intermodal trips – with its ETAs, incidents management, etc.

c) Existence of a “Transport System” willing to support external processing queries. Since a “Processing System” is basically any engine capable of receive and treat semantic queries, a

transport operator could be interested in extending its own processing system – used for its particular transport queries – to interact with other transport systems and offer its clients an enhanced trip planner service.

In all three cases, the feasibility of the use case depends on the capabilities of the query language to

be selected and the richness of the available ontologies and data. Establishing a third party retrieving data from different operators to later on build an intermodal trip

planner, is something commonly used by current trip engines. However, the interest within the project is on the customized information that could be delivered to the end-user, which relies, not only on the data that must come from the transport operator, but also on the data provided by the traveler.

4.1.3 Use Case 01.2M: Adaptive Intermodal Trip Planner with Park and Ride

Use case Id

UC01.2M

Title Adaptive intermodal trip planner with park and ride Involved building blocks

Discovery Service, Processing System, Transport System, Parking Layer Involved applications

GAMBAS mobile application, Parking Management application Required data

Desired destination, routes, incidents, ETA, position of available parking lots

Offered services Adaptive trip plan, notifications on when to start the trip and incidents on route, automatic booking of parking lot.

Involved partners

UDE, ETRA I+D, NUIG, OU, EMT

Table 3 – Adaptive Intermodal Trip Planner with Park and Ride Summary

This case presents an extension of the previous two uses cases, and specifically of UC01.1M. In this use case, the user wants to go by car to a parking area and then continue its trip to its destination by public transport. This is actually a combination of two adaptive route calculations, plus an automatic parking booking procedure.

The automatic booking procedure was already presented at the PECES project [PECES], where the core of the GAMBAS consortium was also involved (UDE, ETRA, and NUIG). First, the mobile application – with navigation capabilities – calculated the route by car to the closest parking to destination. This already relied on a set of ontologies delivered by the project.

The parking management system was adapted to actually publish 1) its location, 2) the number of available parking lots and 3) a booking service.

Second, with this information, the mobile application was able to book a parking lot and lead the user to it. This was done minimizing the user interactions with the system, without distracting the driver from its main driving activity.

Last but not least, the parking was able to detect the user – associated to a car id by its plate number – accessing the parking and to calculate the associated cost when the user finally left the parking.

Besides the continuation of the use case in order to introduce the intermodality, in this case a park and ride service, the main challenge to be addressed in order to implement this use case, is the different approaches adopted in each project. Whilst in PECES, all the semantic processing was provided by a middleware distributed in each of the applications, in GAMBAS, external processing systems are being established to actually manage information and services from different sources.

This is critical in order to extend the current booking and navigation system, since GAMBAS needs to access information not only from a parking layer, but also from a Transport System. In this way, GAMBAS needs a third party processing system to run a query that will result in an intermodal trip.

Once again, the feasibility of this use case will depend on the capabilities of the query language to be selected and the richness of the available ontologies and data. It is noteworthy mentioning that the parking layer is out of the scope of the project, and therefore, the implementation of this use case cannot be programed without assessing the effort that would require the adaptation of the current available system from the PECES project. This will be done, once the first draft of the architecture is available.

Gambas App

Discovery Service

Processing System

Transport System

Parking Layer

Registre data service Registre service

Select info layers

Registre data service

Discover data services for city

Public data

Capture "GoTo"

announcement

Allow query location (PRF) (CQP) Stream Query Location

Location data Capture "PARKING"

Reserve parking place

Stream query route from to POI (CQP) [mode car]

Query (CQP)

Route data loop travel ( UC01M )

Detect vehicle in parking Stream query route from location to POI/location (CQP) [mode TP] Query (CQP)

in parking

Route data loop travel ( UC01M )

Figure 5 – Adaptive Intermodal Trip Planner with Park and Ride Sequence Diagram

4.1.4 Use Case 02M: Predictive Destination

Use case Id

UC02M

Title

Predictive destination

Involved building blocks Discovery Service, Processing System, Transport System Involved applications

GAMBAS mobile application

Required data User position, routes, historical use of routes and positions Offered services

The GAMBAS mobile application will suggest the user a list of more probable next target actions – in this case next GoTo destinations.

Involved partners

UDE, ETRA I+D, NUIG, OU, EMT

Table 4 – Predictive Destination Summary

The predictive destination use case presents one of the core functionalities under the GAMBAS vision. The application at the smart phone must be able to infer the possible next destination of its user. This will be done by storing on the mobile device the position and routes the user had been using, and making a statistical analysis at the end of each day.

This information could be later available – making use of the privacy framework – by third parties in order to establish joint routes with users sharing same predicted destination.

From the point of view of the user interface, this use case is the one presenting the highest challenge regarding the seamless interaction between the user and the GAMBAS mobile application.

Gambas App

Local DB

Local Agenda

Transport System

capture context ( GO TO, position, inroute, in stop, etc )

save local DB

sync cloud calendar agenda

startup app

Query agenda

Query pattern behavior. Query pattern next GO TO

Stream Query route for GO TO from here (CQP) Route updated with pass estimations

Alert init route Acept/Cancel

Update adaptative route

Figure 6 – Predictive Destination Sequence Diagram

4.1.5 Use Case 03M: Demand Response in Real Time

Use case Id

UC03M

Title

Demand response in real time

Involved building blocks Discovery Service, Processing System, Transport System Involved applications

GAMBAS mobile application, EMT Public Transport Exploitation System

Required data

Desired destination

Offered services Adaptive trip plan, adaptive operations on bus service – e.g. increase the number of buses

Involved partners

UDE, ETRA I+D, NUIG, OU, EMT

Table 5 – Demand Response in Real Time Summary

This use case focuses on the feedback that the public transport operator (EMT) could obtain from data mining systems in real time. The layer that offers transport information to the travelers in real time (Transport System) is capable to detect anomalies in the service. This is the case when there are too many users in a given time window requesting the same destination. This could be the case when

a big event – a concert or a football match – is programmed in the city. The Public Transport Exploitation System could react to this anomaly by increasing the number of

buses in real time. Furthermore, the network operator could modify some routes to attend the increasing demand in one route.

From the point of view of the citizen, it could be informed about alternatives in a route, to shift the demand in accordance to the interest of the operator. The usual way to shift user behavior is by means of incentives (see UC06E) but it could also be achieved, by means of added value services, as the ones the shopping and events layers could provide.

Gambas App

Discovery Service

Processing System

Transport System

PTES EMT

Registre data service

Query stream anormal demand

Registre service Query route

Query route

capture target context capture target context Pattern detect

anormal demand

Figure 7 – Demand Response in Real Time Sequence Diagram

4.1.6 Use Case 04M: Demand Response from Statistics

Use case Id

UC04M

Title

Demand response from statistics

Involved building blocks Discovery Service, Processing System, Transport System Involved applications

GAMBAS mobile application, EMT Public Transport Exploitation System

Required data

Desired destination

Offered services Adaptive trip plan, Adaptive operations on bus service – e.g. increase the number of buses

Involved partners

UDE, ETRA I+D, NUIG, OU, EMT

Table 6 – Demand Response from Statistics Summary

With the same retrieved data as in the previous use case, the public transport operator could not only ask for anomalies but also to analyzed the information a posteriori in order to affect the different bus lines and schedules to improve the quality of the service.

This is particularly important when a new line is opened and the number of buses per line and timings need to be adjusted.

4.1.7 Use Case 05M: QoS Indicator through Estimation of Passengers per Bus

Use case Id

UC05M

Title QoS indicator through estimation of passengers per bus Involved building blocks

Discovery Service, Transport System

Involved applications

EMT Public Transport Exploitation System

Required data

MAC addresses detected inside the buses

Offered services

Report on the lines with highest occupancy

Involved partners

UDE, ETRA I+D, NUIG, OU, EMT

Table 7 – QoS Indicator through Estimation of Passengers per Bus Summary

The control unit inside the bus (BIT) is capable of detecting the MAC address of the smart phone entering and leaving the bus – see Figure 8. This will be used to calculate an estimated number of passengers in each bus.