In-Time

Intelligent and Efficient Travel Management

for European Cities




WP3
D 3.1.2 UML schemes finalized - Specification

Version
1.0


Dissemination level
Public




In-Time is a Pilot Type B Project funded by the
European Commission, DG Information Society and Media
in the CIP-ICT-PSP-2008-2 Programme

In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 2 of 56
Contract Number:
CIP-ICT-PSP-2008-2 Nr. 238880
Acronym:
In-Time
Title:
Intelligent and Efficient Travel Management for European Cities
Main author(s) or editor(s):
Jan Borkovec (TMX)
Michele Masnata (SOF)

Other author(s):
Francesco Alesiani (MIZ)
Marco Garr (SOF)
Hannes Koller (ARS)
Rainer Rehberger (ACG)
Karl Schedler (MIC)


In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 3 of 56
Version History:
Version Date Main author(s) Summary of changes
0.1 19/02/10 Jan Borkovec TOC
0.2 18/03/10 Michele Masnata
Marco Garr
Comments and suggestions to the
document structure and concept.
Provision of use-case diagrams for the
document.
0.3 29/03/10 Jan Borkovec Use case diagrams added for each
service.
0.4 6/04/10 Jan Borkovec Introductive chapters extended.
Document extended with high-level
definitions of feature types required for
each use-case.
0.5 1/04/10 Michele Masnata Revision of the document. The
introductive chapters Scope of the
document and Methodology modified
and extended.
0.6 7/04/10 Karl Schedler Minor correction and update of the
service 15 Dynamic Weather
information.
0.7 14/04/10 Francesco Alesiani Minor correction and update of the
service 12 Dynamic Freight
Information.
0.8 31/04/10 Rainer Rehberger
Hannes Koller
During the internal review these parts
of the documents were proposed to be
modified: Static road information
service, Static and Dynamic flight
information service.
0.9 04/05/10 Jan Borkovec Minor corrections and updates based
on internal review process.
1.0 07/05/10 Jan Borkovec Correction of typos. The table
describing the history of the document
was updated. Final release version.

In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 4 of 56
List of the In-Time Project Partners:
Partner no. Partner name Partner short
name
Country
1 AustriaTech - Federal Agency for Technological Measures
Ltd.
ATE AT
2 Tele Atlas BV TAT NL
3 BRIMATECH Services GmbH BRI AT
4 Mizar Automazione S.P.A MIZ IT
5 Universitatea Politehnica din Bucuresti UPB RO
6 SINTEF Technology and Society SIN NO
7 Verkehrsverbund Ost-Region (VOR) Ges.m.b.H. IVR AT
8 ASFINAG Maut Service GmbH ASF AT
9 Telematix Software, a.s. TMX CZ
10 Left intentionally blank
11 Fluidtime Data Service GmbH FLU AT
12 PTV Planung Transport und Verkehr AG PTV DE
13 European Road Transport Telematics Implementation and
Coordination Organisation SCRL
ERT BE
14 Swarco Futurit Verkehrssignalsysteme GmbH SWA AT
15 Brnnsk komunikace a.s. BKO CZ
16 ATAF spa ATA IT
17 Softeco Sismat S.p.A. SOF IT
18 micKS MSR GmbH MIC DE
19 Geo Solutions nv GEO BE
20 sterreichisches Forschungs- und Prfzentrum Arsenal
Ges.m.b.H.
ARS AT
21 Memex Srl MEM IT
22 Austro Control - sterreichische Gesellschaft fr
Zivilluftfahrt
ACG AT
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 5 of 56
Table of Contents
List of Figures 7
1 Scope of the document 9
2 Methodology 11
2.1 Scope of the UML diagrams and High-level specifications 12
3 UML Diagrams 13
3.1 In-Time Service 1 Static Road Traffic Information 13
3.1.1 RDSS Response-high level 14
3.1.2 Use case diagram 14
3.2 In-Time Service 2 Dynamic Road Traffic Information on higher network (TMC quality) 15
3.2.1 RDSS Response-high level 16
Real time traffic info- type of event 16
3.2.2 Use case diagram 17
3.3 In-Time Service 3 Static Parking Information 17
3.3.1 RDSS Response-high level 18
3.3.2 Use case diagram 19
3.4 In-Time Service 4 Static Public Transport Information 20
3.4.1 RDSS Response-high level 20
3.4.2 Use case diagram 21
3.5 In-Time Service 5 Walking Information 22
3.5.1 RDSS Response-high level 23
3.5.2 Use case diagram 24
3.6 In-Time Service 6 Dynamic Road Traffic Information for secondary road network 25
3.6.1 RDSS Response-high level 26
Real time traffic info- type of event 26
3.6.2 Use case diagram 27
3.7 In-Time Service 7 Dynamic Public Transport Information 27
3.7.1 RDSS Response-high level 28
3.7.2 Use case diagram 29
3.8 In-Time Service 8 Dynamic Public Transport Journey Routing 29
3.8.1 RDSS Response-high level 30
3.8.2 Use case diagram 31
3.9 In-Time Service 9 Dynamic Parking Information 32
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 6 of 56
3.9.1 RDSS Response-high level 32
3.9.2 Use case diagram 33
3.10 In-Time Service 10 Enhanced Walking Planning 34
3.10.1 RDSS Response-high level 35
3.10.2 Use case diagram 35
3.11 In-Time Service 11 Dynamic Cycling Planning 36
3.11.1 RDSS Response-high level 37
3.11.2 Use case diagram 38
3.12 In-Time Service 12 Dynamic Freight Traffic Information 39
3.12.1 RDSS Response-high level 41
3.12.2 Use case diagram 41
3.13 In-Time Service 13 Dynamic POI Information 42
3.13.1 RDSS Response-high level 43
3.13.2 Use case diagram 44
3.14 In-Time Service 14 Dynamic Traffic Event Information 45
3.14.1 RDSS Response-high level 45
3.14.2 Use case diagram 46
3.15 In-Time Service 15 Dynamic Weather Information 47
3.15.1 RDSS Response-high level 48
3.15.2 Use case diagram 49
3.16 In-Time Service 16 Static and Dynamic Flight Information 49
3.16.1 RDSS Response-high level 50
3.16.2 Use case diagram 51
3.17 In-Time Service 17 Comparative Dynamic Multi Modal Journey Planning 51
3.17.1 RDSS Response-high level 54
3.17.2 Use case diagram 54
4 Conclusion 56

In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 7 of 56
List of Figures
Figure 3-1: Service chain for Static Road Information........................................................................ 13
Figure 3-2: Service chain for Static Road Information........................................................................ 13
Figure 3-3: Use case Diagram of Service 1........................................................................................ 15
Figure 3-4: Service Chain for Dynamic Road Traffic Information Service.......................................... 16
Figure 3-5: Use Case Diagram of service 2........................................................................................ 17
Figure 3-6: Service Chain for Static Parking Information ................................................................... 18
Figure 3-7: Use Case Diagram of Service 3....................................................................................... 19
Figure 3-8: Service Chain for Static Public Transport Information ..................................................... 20
Figure 3-9: Use Case Diagram of Service 4....................................................................................... 22
Figure 3-10: Service Chain for Enhanced Walking Planning.............................................................. 23
Figure 3-11: Use Case Diagram of Service 5.................................................................................... 25
Figure 3-12: Service Chain for Dynamic Road Information for secondary road network ................... 26
Figure 3-13: Use Case Diagram of Service 6.................................................................................... 27
Figure 3-14: Service Chain for Dynamic Public Transport Information .............................................. 28
Figure 3-15: Use Case Diagram of Service 7..................................................................................... 29
Figure 3-16: Service Chain for Dynamic Public Transport Journey Routing...................................... 30
Figure 3-17: Use Case Diagram of Service 8.................................................................................... 31
Figure 3-18: Service Chain for Dynamic Parking Information ............................................................ 32
Figure 3-19: Use Case Diagram of Service 9.................................................................................... 33
Figure 3-20: Service Chain for Enhanced Walking Planning.............................................................. 34
Figure 3-21: Use Case Diagram of Service 10.................................................................................. 36
Figure 3-22: Service Chain for Dynamic Cycling Planning................................................................. 37
Figure 3-23: Use Case Diagram of Service 11................................................................................... 39
Figure 3-24: Service Chain for Dynamic Freight Traffic Information .................................................. 40
Figure 3-25: Use Case Diagram of Service 12.................................................................................. 42
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 8 of 56
Figure 3-26: Service Chain for Dynamic POI Information .................................................................. 43
Figure 3-27 Use Case Diagram of Service 13................................................................................... 44
Figure 3-28: Service Chain for Dynamic Traffic Event Information .................................................... 45
Figure 3-29: Use Case Diagram of Service 14.................................................................................. 47
Figure 3-30 Service Chain for Dynamic Weather information ............................................................ 48
Figure 3-31: Use Case Diagram of Service 15................................................................................... 49
Figure 3-32: Service Chain for Static and Dynamic Flight Information............................................... 50
Figure 3-33: Use Case Diagram of Service 16.................................................................................. 51
Figure 3-34: Service Chain for Dynamic Multi-modal Journey Routing- RDSS route generation...... 52
Figure 3-35: Service Chain for Dynamic Multi-modal Journey Routing- TISP route generation........ 53
Figure 3-36: Use Case Diagram of Service 17.................................................................................. 55


In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 9 of 56
1 Scope of the document
This document is a part of the SWP 3.1 System Specification and Adaptation. The aim of this
document is to provide a high-level description of each use-case realization of the In-Time system for
the specific implementation in the six In-Time pilot cities. Main objectives of this report is to provide a
reference specification which describes common functional blocks and analyzes common data
elements and processes as well as the expected information flow for each of the In-Time services
defined in WP2 (Deliverable D2.4.1). This will enable a cross-check of functionalities and should
ensure consistency and homogeneity in the implementation. The present analysis and specification
make use of UML components diagrams showing, for each use case, the interaction of data and
services in the In-Time value chain in terms of end-user, TISP and RDSS components and their high
level interfaces. Use case diagrams are also defined to have a user-oriented view of the information
flow.
Starting points for the definition of the common UML schemes and descriptions are:
a) The definition of In-Time services (D2.4.1) for UML component diagrams (describing
functional blocks, nodes, information flow from the point of view of the system components)
and UML use case diagrams (describing user interactions and the information flow from the
point of view of the end user service)
b) A high-level definition of features (pieces of information) to be supported by the In-Time
Commonly Agreed Interface to enable the implementation of each of the 17 In-Time
services.
Point b) refers to an activity which represents a selection of the necessary sub-set of data and
services from the complete and rather extended In-Time specification which make provision of a very
detailed model aiming at covering a very large number of situations and domains, usually not found
(all together) in a single pilot city. The selection of the necessary sub-set of the CAI feature
specification -a tailoring operation made possible by the characteristics of the specification itself-
was carried out as a common activity by In-Time partners: it started from an individual analysis of
TISPs requirements and pilot specific needs and it was concluded by putting together and
harmonizing every detected feature.
This activity has to be considered actually the very first (high-level) step of the implementation
process and not part of the production of the specification itself.
The (complete) specification of the interface is a task addressed by Deliverable D3.2.1 and it is
driven by a different approach and background.
The high-level feature specification is limited to the specific requirements of the six In-Time pilot
sites. For this reason whereas functional block definitions (UML component diagrams) are reflecting
the organization and connection of system components and this is not the result of specific pilot
choices and can be considered as a reference design indication, the high-level specification of the
necessary features constitutes only a reference for the present In-Time project implementation
because it has been defined by harmonizing single and specific requirements. This shall constitute
only an example of what followers cites have to do in order to start an In-Time implementation from
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 10 of 56
the technical point of view. The specification of the complete, extended interface, suitable for a
specific implementation in following cities, is defined in Deliverable D3.2.1.
The High-level identification of the necessary CAI features (also called minimum requirements of
the CAI) is the driver for the definition of that part of the complete In-Time specification (defined in
D3.2.1) to be applied to the six pilot cities. This (pilot-specific) definition, together with the
presentation of the technological solutions chosen by each Pilot city is presented in Deliverable
D3.4.1
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 11 of 56
2 Methodology
Each In-Time service is presented in terms of use-case and deployment diagrams as well as high-
level requirements that are expected from RDSS as response to each TISP requests. This shall help
to understand how each use-case can be realized.
From the perspective of the concrete implementation which will be carried out in In-Time, Services
can be distinguished according to where the In-Time service is generated. There are services that
need to be created at RDSS side. These services do not include journey routing that can otherwise
be done also by TISP (except for Public Transport Journey Routing
1
):
Services provided from the RDSS site:
Dynamic Road information on higher network
Dynamic Road information on secondary network
Static parking information
Dynamic parking information
Static Public Transport information
Dynamic Public Transport Information
Dynamic Public Transport Journey routing
Dynamic POI information
Dynamic traffic Event information
Dynamic Weather Information
Static and dynamic flight information
Other services may be provided either by the RDSS or TISPs. Typically services including journey
routing function such as:
Static walking information
Enhanced walking planning
Dynamic cycling planning
Dynamic freight traffic information
Comparative Dynamic Multi Modal Journey Planning
Static Road Traffic Information


1
GeoSolutions requires Public Transport journey routing service from RDSS server. Requirements
from TelMap were not known at the time of creation of this document

In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 12 of 56
may have the route generation either at the RDSS side (TISP gets a set of waypoints for every
network segment, arrival times and changing points for public transport), or TISP will generate
routing itself based on the provided dynamic attributes, that modify the static features of road
network (speed profiles, work closures, cycle path, walking obstacles, etc..). These dynamic features
may be provided for car and truck routing as well as for pedestrian or bicycle routing.
2.1 Scope of the UML diagrams and High-level specifications
The methodology that has been selected for the UML schemes is based on the Deployment
diagrams and Use case diagrams modelled in Enterprise Architect software. Use-case diagrams
show the relationship and interactions between actors End-user, TISP, RDSS and Other service
provider. Deployment diagrams provide higher level of abstraction than class diagrams, because
component may be implemented by one or more classes. This is the reason, why component
diagrams were selected in this high-level UML model, because this representation avoids the
problem of describing different subset of classes among pilot cities. This allows having common
diagrams for every pilot, where RDSS component is a Data service- it basically provides In-Time
data or services to TISP and get native data from local data sources.
However some use-cases may be achieved more than one way depending on whether RDSS
provides a service or data to TISP. Therefore for every use-case, there is a remark that defines the
possibilities of the service provision.
UML diagrams presented in this report can be assumed to be applicable to (or constitute a reference
for) every pilot city, even followers cities, as they are the result of a common analysis based on the
accepted In-Time service definition.
Besides these models which describes the In-Time system from the functional point of view as well
as from the perspective of the information flow- a definition has been also included in terms of high-
level features to be supported by the In-Time Commonly Agreed Interface to provide each of the 17
In-Time services.
As already introduced, this definition is the result of a process of identification of the features
necessary for the implementation of the services collected starting from RDSSs and TISPs
requirements. This lead to a harmonized and common specification of high-level requirements which
will be reflected, in a more detailed phase of the implementation activity, in a selection of the subset
of the In-Time data model suitable for the concrete specification and realization of the necessary
data services, according to the architectural principles exposed in Deliverable D2.3.1 (Report on In-
Time Interfaces and Protocols)
This high-level specification of the necessary features of the C.A.I. and also the specific and detailed
subset of the In-Time data model specifically tailored for the concrete implementation in the six In-
Time pilot cities shall constitute an example and a tutorial for followers cities (whereas UML
diagrams can be assumed to be applicable also to followers cities). On the other hand, the complete,
extended and detailed specification suitable for an implementation in followers city, is presented in
Deliverable D3.2.1.
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 13 of 56
3 UML Diagrams
3.1 In-Time Service 1 Static Road Traffic Information
The following examples describe a request from the end-user application that is associated with the
provision of a static road network. The static road network can be either provided by the TISP itself
by allowing installation of digital maps in the end-user PDAs (figure 3-1) or will be provided via WFS
interface from the RDSS (figure 3-2).
End User Service
End User
Application
TISP
End User Service
Static Road map

Figure 3-1: Service chain for Static Road Information

RDSS
TISP
End User Service
WFS:getStati cRoadData
devi ce
End User Device
Road traffic information service
Road Data
Road information
(static)
WFS

Figure 3-2: Service chain for Static Road Information

In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 14 of 56
1. This service is initiated in case the end-user asks for (multi-modal) routing from point A to B
or wants to specify area or point in the map.
2. TISP sends request to the RDSS to provide static road information defined through upper-
right, lower-left corners.
3. Based on this request RDSS provides the TISP static road information.

Note: Depending on the route length from the origin to the destination a large part of the map may
be required to transfer from the RDSS to the TISP. Performing this transfer every time a routing is
requested will be very inefficient. A more efficient strategy would be for the TISP to keep a copy of
the entire map in a local cache and use the cached road data to answer end-user requests.

3.1.1 RDSS Response-high level
This information is related to the specific implementation in the 6 In-Time cities. It does not
constitute a specification for In-Time. The complete specification can be found in D3.2.1.
RDSS will return map window. Minimum requirements include road related features Road links and
Road nodes.
Minimum attributes for Road Links:
Road geometry: length, shape
Functional road class (high way, urban, 1. Class, 2. class)
Road number (R1, D5,)
Form of way (bicycle road, walkway, motorway, enclosed traffic area)
One ways
Street names and street numbers
avg. speed per road segment or speed profiles


Minimum attributes for Road nodes:
Junction
Roundabout
Road end.


3.1.2 Use case diagram
The following Use case diagram illustrates the interaction between the end user, the TISP, the RDSS
with a highlight on the functionalities provided by each In-Time service. It is a reference way of
representing the working principles of the user interaction with the In-Time system.
The definition is based on the analysis in D2.4.1
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 15 of 56
End User
Specifies a point
Geo-Coding
Interactive sel ection
on map
Get static information
(point or area)
Get speed limit
Get Road Type
Get Route
Get Restrictions
get GPS position
Specifi es Origin and
Destination
Get static information
(road)
Get Di stance
Specifies an area
RDSS
Road Network data
Integrate Road
network and map
information
TISP
End User Application
Other Servi ce Provider
Map Data
Get Static Road
traffic Information
Specify an address
(or PT stop)
i ncl ude
incl ude
i ncl ude
i ncl ude
i nclude
precedes
i nclude
provi de
use
precedes
incl ude
i ncl ude
use
i ncl ude
i ncl ude
provi de
provi de
i ncl ude
use
precedes
i ncl ude
provi de
use
real ize
use
provi de
i ncl ude

Figure 3-3: Use case Diagram of Service 1

3.2 In-Time Service 2 Dynamic Road Traffic Information on higher
network (TMC quality)
In the following use-case the RDSS provides instant (or future) description of road network traffic
condition. This may include temporary road closures, information about traffic levels or events such
are car accidents. The location reference methodology enables to assign all traffic events to the
exact location on the road network. Provision of this service is necessary for the dynamic vehicle
journey routing because based on this service TISP provides vehicle routing as a subset of service
17. Another option is that the RDSS not only provides dynamic traffic information as standalone
data, but generates dynamic vehicle routing itself by means of provision of waypoints for navigation
to the TISP.
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 16 of 56
RDSS
TISP
End User Service
WFS:
getDynami cRoadTraffi c
devi ce
End User Device
Road Data
Dynamic road traffic information
Dynami c Road Traffi c
Data
Road Traffic Data
Service (dynamic)
WFS

Figure 3-4: Service Chain for Dynamic Road Traffic Information Service

1. This service is initiated in use-cases when the end-user asks for (multi-modal) routing from
point A to B or specifies a point or location in the map.
2. Based on this request, the RDSS provides to the TISP dynamic information about the current
state of the road network conditions through WFS interfaces.

3.2.1 RDSS Response-high level
This information is related to the specific implementation in the 6 In-Time cities. It does not
constitute a specification for In-Time. The complete specification can be found in D3.2.1.
Real time traffic info- type of event
Mandatory amount of information provided by the RDSS to the TISP is proposed to include
temporary changes in static road network i.e. road closures and road works and dynamic traffic
levels for road segments. Information about various kind of traffic events are also required.
Mandatory
Road closures (for defined time validity)
Road works (one lane closure, temporary one way road, etc..)
Traffic levels=> Dynamic average speed for particular road segment
Traffic events (car accidents, car repair, obstacles on the road, etc..)



In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 17 of 56
3.2.2 Use case diagram
The following Use case diagram illustrates the interaction between the end user, the TISP, the RDSS
with a highlight on the functionalities provided by each In-Time service. It is a reference way of
representing the working principles of the user interaction with the In-Time system.
The definition is based on the analysis in D2.4.1
End User
Geo-Coding
Interactive selection
on map
Specifies a point
Specifies additional
criterias
Get Dynamic Traffic
Information
Specify type of
dynamic Information
Specify type of
disturbance
Specify period of
validity
Get disturbance
notifications
Get camera pictures
RDSS TISP
End User Application
Provide Dynamic
Road Data
Integrate Dynamic
Data and Map Data
Other Service Provider
Map Data
Specify an address
(or PTstop)
Specifies an area
Specifies Origin and
Destination use
i ncl ude i ncl ude
precedes
i ncl ude
i ncl ude
real i ze
use
use
i ncl ude
provi de
provi de
provi de
provi de
i nvokes
i ncl ude
i ncl ude
i ncl ude
use
precedes
precedes
precedes
precedes

Figure 3-5: Use Case Diagram of service 2

3.3 In-Time Service 3 Static Parking Information
The following use-case provides geographic position of parking facilities placed on the static road
map. For every parking facility additional useful information is provided. Static parking information is
provided by the RDSS.
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 18 of 56
RDSS
TISP
End User Service
WFS:
getStati cParki ngInformati on
devi ce
End User Device
Road Data
Static parking information
Stati c parki ng data
Parking information
(static)
WFS

Figure 3-6: Service Chain for Static Parking Information

1. This service is initiated in end-user application, when the end-user asks TISP for
Park&Ride instructions.
2. TISP asks the RDSS server to provide static parking information from his
GetStaticParkingData interface.
3. Based on this request, the RDSS provides the TISP static parking information.

3.3.1 RDSS Response-high level
This information is related to the specific implementation in the 6 In-Time cities. It does not
constitute a specification for In-Time. The complete specification can be found in D3.2.1.
Information that must be provided by the RDSS to the TISPs are:
Parking Point (name, location, description)
Tariffs (fee type (daily, etc..), description)
Basic Data (total capacity, permitted vehicles, accessibility status for mobility impaired, etc..)
Parking Entrances (location)
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 19 of 56
These represents the minimum set of information needed to satisfy the static part of the
requirements coming from the TISP. It must be underlined that some other basic static information
that maybe could be provided easily by the RDSS, e.g. Opening Times, are not taken into account
in this document because they are not explicitly indicated by TISPs.

3.3.2 Use case diagram
The following Use case diagram illustrates the interaction between the end user, the TISP, the RDSS
with a highlight on the functionalities provided by each In-Time service. It is a reference way of
representing the working principles of the user interaction with the In-Time system.
The definition is based on the analysis in D2.4.1

Specifies an area
Specifies a point
Interactive selection
on map
Geo-Coding
get GPS position
End User
Specify additional
parking requirements
Get Static parking
information
Other Service Provider
RDSS
TISP
Map Data
Integrate Map Data
and Parking Data
Provide Static
Parking Data
End User Application
Specify an address
(or PTstop)
i nvokes
real i ze
precedes
use
precedes
use
provi de
provi de
use
provi de
precedes
provi de
i ncl ude
use
i ncl ude
i ncl ude
use
provi de

Figure 3-7: Use Case Diagram of Service 3
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 20 of 56
3.4 In-Time Service 4 Static Public Transport Information
The following use-case provides static public transport information related to all PT modes available
in each pilot city. The service offers geographical positions of PT stops and the corresponding
timetables related to PT stop and PT line.
RDSS
TISP
End User Service
WFS:
getStati cPubl i cTransport
devi ce
End User Device
Road Data
Static public transport information
Stati c publ i c transport data
Public Transport
(static)
WFS

Figure 3-8: Service Chain for Static Public Transport Information
1. This service is initiated in end-user application, when end-user asks TISP to find PT stop in
selected area with corresponding static arrival/departure times for PT lines. End user selects
in the map desired origin or destination point and start time or arrival time.
2. Based on this request, TISP asks RDSS by interface WFS:getStaticPublicTransport for
provision of the nearest PT stops according to end-user selection. The RDSS response with
GPS location of PT stops possible.
3. End-user selects the PT stop and TISP asks again the RDSS by interface
WFS:getStaticPublicTransport for provision of the static PT information (line,
arrival/departure, terminal station) related to the selected PT stop.

3.4.1 RDSS Response-high level
This information is related to the specific implementation in the 6 In-Time cities. It does not
constitute a specification for In-Time. The complete specification can be found in D3.2.1.
Public Transport information requested by TISP is essentially related to Stop Point (Fixed
Infrastructure information) and Schedules at this stop (Stop-Point centric view).
In particular useful information that must be provided by the RDSS to the TISPs are:
Stop Point (name, location, stop code)
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 21 of 56
Line (name, direction, sequential stop points for the journey (opt))
Operator (name, description)
Timetables (Arrival time and departure time at stops)
These information are naturally linked, e.g. Operator operates a Line which has a Journey (or a
ServiceDescription) describing the sequence of Stop Points that will be visited providing also an
arrival time and a departure time.

3.4.2 Use case diagram
The following Use case diagram illustrates the interaction between the end user, the TISP, the RDSS
with a highlight on the functionalities provided by each In-Time service. It is a reference way of
representing the working principles of the user interaction with the In-Time system.
The definition is based on the analysis in D2.4.1
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 22 of 56
Geo-Coding
End User
Specify Start time
Specify
Mode/Service/Operator
Specify Additional
Parameters
Get Static Public
Transport Information
Get Stop Name /
Infrastructure
information
Interactive selection
on map
Specifies a point
Specify an address
(or PT stop)
Get static
timeschedules for
selected line or service
RDSS
Other Service Provider
TISP
Map Data
End User Application
Provide Static PT
Information
Integrate PT
information and map
data
i ncl ude
i ncl ude
i ncl ude
real i ze
use
precedes
use
precedes
precedes
use
provi de
provi de
provi de
i nvokes
provi de
i nvokes
i ncl ude
i ncl ude
i ncl ude
use

Figure 3-9: Use Case Diagram of Service 4


3.5 In-Time Service 5 Walking Information
The following use-case provides routing for pedestrians based on the static map. The service can be
provided by TISP itself or provided via WFS from the RDSS. As depicted in figure 3-11 RDSS is a
walking data provider and TISP generates the routing service out of the walking data.
Another option is that the RDSS generates dynamic routing itself by means of provision of waypoints
for walking navigation to TISP. This routing is then part of the service 17, where simultaneous multi-
modal routing is provided.

In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 23 of 56

RDSS
TISP
End User Service
WFS:
getStati cWal ki ngData
devi ce
End User Device
Road Data
Road traffic information service
Road Data
Walking information
(static)
WFS
Wal ki ng Data

Figure 3-10: Service Chain for Enhanced Walking Planning

1. This service is initiated in the end-user application, when end-user asks for multi-modal
routing from point A to B. The generated multi-modal route most probably includes walking
part.
2. When walking is a part of the selected journey, TISP asks the RDSS by interface
WFS:getStaticWalkingData to provide static walking information.
3. Based on the request the RDSS provides TISP StaticWalkingData through WFS interface.

3.5.1 RDSS Response-high level
This information is related to the specific implementation in the 6 In-Time cities. It does not
constitute a specification for In-Time. The complete specification can be found in D3.2.1.
The RDSS shall provide network routes suitable for pedestrians. This kind of network shall include:
Walkways
Pedestrian zones
Sidewalks
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 24 of 56
The walking routing information is part of the multi-modal routing service 17, where walking stage is
a part of multi-modal routing information.
With respect to this isolated service, high-level requirements for walking are required from the RDSS:
Starting point and destination point of walking
Walking instructions / navigation via waypoints
Time duration of walking stage

3.5.2 Use case diagram
The following Use case diagram illustrates the interaction between the end user, the TISP, the RDSS
with a highlight on the functionalities provided by each In-Time service. It is a reference way of
representing the working principles of the user interaction with the In-Time system.
The definition is based on the analysis in D2.4.1

In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 25 of 56
Specifies an area
Specify an address
(or PTstop)
Interactive selection
on map
End User
Enter Specific
Walking Planning
Criteria
Specify Obstacles to
Avoid
Get Walking Information
RDSS
Other Service Provider
TISP
Map Data
End User Application
Walking data
Integrate Walking
data and map data
Specifies a point
Geo-Coding
provide
i nclude
precedes
reali ze
use
precedes
use
provi de
use
provide
precedes
i nvokes
provi de
incl ude
incl ude
i ncl ude
use
provi de

Figure 3-11: Use Case Diagram of Service 5


3.6 In-Time Service 6 Dynamic Road Traffic Information for
secondary road network
In the following use-case the RDSS provides dynamic traffic info as time-variable traffic and network
features that are offered to TISP for their actual routing adaptation. This is the case the RDSS is a
data provider and TISP generates the routing service (figure 3-14). Another option is that the RDSS
does not provide only dynamic information as standalone data, but generates dynamic routing itself
(based on their own proprietary dynamic road traffic information) by means of provision of waypoints
for navigation to TISP. Then this routing is a part of the service 17, where simultaneous multi-modal
routing is provided.

In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 26 of 56
RDSS
TISP
End User Service
WFS:
getDynami cRoadTraffi c
devi ce
End User Device
Road Data
Dynamic road traffic information
Dynami c Road Traffi c Data
Road Traffic Data
Service (dynamic)
WFS

Figure 3-12: Service Chain for Dynamic Road Information for secondary road network

1. This service is initiated in use-cases when the end-user asks for (multi-modal) routing from
point A to B or specifies a point or location in the map.
2. Based on the TISP request, the RDSS provides to the TISP dynamic information about the
current state of the road network conditions through WFS interface getDynamicRoadData.

3.6.1 RDSS Response-high level
This information is related to the specific implementation in the 6 In-Time cities. It does not
constitute a specification for In-Time. The complete specification can be found in D3.2.1.
RDSS response is the same as in case of service 2.
Real time traffic info- type of event
Mandatory amount of information provided by the RDSS to the TISP is proposed to include
temporary changes in static road network i.e. road closures and road works and dynamic traffic
levels for road segments. Information about various kinds of traffic events is also required.
Mandatory
Road closures (for defined time validity)
Road works (one lane closure, temporary one way road, etc.)
Traffic levels=> Dynamic average speed for particular road segment
Traffic events (car accidents, car repair, obstacles on the road, etc.)


In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 27 of 56
3.6.2 Use case diagram
The following Use case diagram illustrates the interaction between the end user, the TISP, the RDSS
with a highlight on the functionalities provided by each In-Time service. It is a reference way of
representing the working principles of the user interaction with the In-Time system.
The definition is based on the analysis in D2.4.1
End User
Geo-Coding
Interactive selection
on map
Specifies a point
Specifies additional
criterias
Get Dynamic Traffic
Information
Specify type of
dynamic Information
Specify type of
disturbance
Specify period of
validity
Get disturbance
notifications
Get camera pictures
RDSS TISP
End User Application
Provide Dynamic
Road Data
Integrate Dynamic
Data and Map Data
Other Service Provider
Map Data
Specify an address
(or PT stop)
Specifies an area
Specifies Origin and
Destination use
i ncl ude i ncl ude
precedes
i ncl ude
i ncl ude
real i ze
use
use
i ncl ude
provi de
provi de
provi de
provi de
i nvokes
i ncl ude
i ncl ude
i ncl ude
use
precedes
precedes
precedes
precedes

Figure 3-13: Use Case Diagram of Service 6


3.7 In-Time Service 7 Dynamic Public Transport Information
The following use-case provides dynamic public transport information related to all PT modes
available for each pilot. The service offers geographical positions of PT stops and the corresponding
timetables related to PT stop and PT line. The dynamic timetables include forecast of the next
passages, qualitative conditions of transport service, waiting times, regularity of service, etc.

In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 28 of 56
RDSS
TISP
End User Service
WFS:
getDynami cPubl i cTransport
devi ce
End User Device
Road Data
Dynamic public transport information
Dynami c publ i c transport data
Public Transport
(dynamic)
WFS

Figure 3-14: Service Chain for Dynamic Public Transport Information

4. This service is initiated in end-user application, when end-user asks TISP to find PT stop in
selected area with corresponding dynamic arrival/departure times for PT lines. End user
selects in the map desired origin or destination point and start time or arrival time.
5. Based on this request, TISP asks RDSS by interface WFS:getStaticPublicTransport for
provision of the nearest PT stops according to end-user selection. The RDSS response with
GPS location of PT stops possible.
6. End-user selects the PT stop and TISP asks again RDSS by interface
WFS:getStaticPublicTransport for provision of the dynamic PT information (line,
arrival/departure, terminal station) related to the selected PT stop.

3.7.1 RDSS Response-high level
This information is related to the specific implementation in the 6 In-Time cities. It does not
constitute a specification for In-Time. The complete specification can be found in D3.2.1.
This dynamic information related to arrival and departure times can be realized from RDSS as a
periodical update on these values for the specified Stop Point.
Other relevant information that could be interest is:
regularity of service
news
transport services changed/cancelled


In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 29 of 56
3.7.2 Use case diagram
The following Use case diagram illustrates the interaction between the end user, the TISP, the RDSS
with a highlight on the functionalities provided by each In-Time service. It is a reference way of
representing the working principles of the user interaction with the In-Time system.
The definition is based on the analysis in D2.4.1

End User
Geo-Coding
Specify an address
(or PT stop)
Interactive selection
on map
Specify Additional
Parameters
Specify Start/Arrival
Time
Specify
Mode/Service/Operator
Specifies a point
Get dynamic Public
Transport Information
Specify period of
validity
Get forecasted
schedules
RDSS
TISP
Other Service Provider
End User Application
Map Data
Dynamic PT
Information
Integrate PT
Information and Map
Data
Get Static Public
Transport Information
use
use
real i ze
i ncl ude
i ncl ude
precedes
i ncl ude
precedes
use
i ncl ude
provi de
provi de
provi de
i nvokes
provi de
i nvokes
i ncl ude
i ncl ude
i ncl ude
use
precedes

Figure 3-15: Use Case Diagram of Service 7


3.8 In-Time Service 8 Dynamic Public Transport Journey Routing
The following use-case provides the public transport routing based on the dynamic public transport
data. The service will be provided by a set of textual instructions defining for each journey starting
point, changing point, departure stop and travel time. The service is provided by the RDSS.
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 30 of 56

RDSS
TISP
End User Service
getPTRoute
devi ce
End User Device
Road Data
Public Transport Journey Planning Service
Dynami c Publ i c Transport Data
Public Transport
Journey Planning
Application

Figure 3-16: Service Chain for Dynamic Public Transport Journey Routing

1. This service is initiated in the end-user application, when end-user asks for multi-modal
routing from point A to B.
2. When public transport is a part of the selected journey (by explicit request of the user), TISP
asks the RDSS by interface WFS:getPTRoute to provide dynamic PT route.

3.8.1 RDSS Response-high level
This information is related to the specific implementation in the 6 In-Time cities. It does not
constitute a specification for In-Time. The complete specification can be found in D3.2.1.
This service is a part of Service 17 Multi-Modal Journey Planning, where dynamic Public transport
Routing is a part of multi-modal routing information. The public transport journey routing is offered
as a possibility out of the several travel choices or is an integral part of a multi-modal journey.
With respect to this isolated routing service, high-level requirements required from RDSS are:
Starting point and destination point of the route (i.e. name of the departure and arrival
station)
ETA (Estimated Time of Arrival) on destination (including starting time and arrival time) for
returned solution
Number of interchanges (via points)
Public transport line identification (e.g. bus number)
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 31 of 56
Location of a station (lat/lon, OPEN LR)
3.8.2 Use case diagram
The following Use case diagram illustrates the interaction between the end user, the TISP, the RDSS
with a highlight on the functionalities provided by each In-Time service. It is a reference way of
representing the working principles of the user interaction with the In-Time system.
The definition is based on the analysis in D2.4.1
End User
Specifies Origin and
Destination
Interactive selection
on map
Geo-Coding
Specify
Mode/Service/Operator
Specify Additional
Parameters
Specify Start time
Specify Via Point
Specify preferences
(preferred mode,
cost, ...)
Get Public Transport
Routing Information
Get Dynamic Times, Stop
names, modes, services,
lines, change information
Get Infrastructure
information
Specify special
travel requirements
Other Service Provider
RDSS
TISP
End User Application
Map Data
Dynamic PTData
Integrate PTData and
Map Data
Calculate PT Route
Specify an address
(or PT stop)
use
i ncl ude
i ncl ude
use
use
i ncl ude
precedes
i ncl ude
i ncl ude
precedes
use
real i ze
provi de
provi de
provi de
i nvokes
provi de
i nvokes
i ncl ude
i ncl ude
i ncl ude
i ncl ude
use
precedes
real i ze

Figure 3-17: Use Case Diagram of Service 8

In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 32 of 56
3.9 In-Time Service 9 Dynamic Parking Information
The following use-case provides geographic position of parking facilities placed on the static road
map. For every parking facility additional useful information is provided. Static parking information is
enhanced by additional dynamic features. Dynamic parking information is provided by the RDSS.

RDSS
TISP
End User Service
WFS:
getDynami cParki ngInformati on
devi ce
End User Device
Road Data
Dynamic parking information
Dynami c parki ng data
Parking information
(dynamic)
WFS

Figure 3-18: Service Chain for Dynamic Parking Information

1. This service is initiated in end-user application, when the end-user asks TISP for
Park&Ride instructions.
2. TISP ask the RDSS server to provide dynamic parking information from his
getDynamicParkingInformation interface.
3. Based on this request, RDSS provides TISP dynamic parking information.

3.9.1 RDSS Response-high level
This information is related to the specific implementation in the 6 In-Time cities. It does not
constitute a specification for In-Time. The complete specification can be found in D3.2.1.
Besides static parking information requirements TISP does not specify any requirements regarding
dynamic information. Dynamic content of this service such as dynamic data on occupancy seems
simpler to provide as a periodical update on occupancy status for the specified parking point.
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 33 of 56
3.9.2 Use case diagram
The following Use case diagram illustrates the interaction between the end user, the TISP, the RDSS
with a highlight on the functionalities provided by each In-Time service. It is a reference way of
representing the working principles of the user interaction with the In-Time system.
The definition is based on the analysis in D2.4.1

End User
Specifies an area
Specifies a point
Interactive selection
on map
get GPS position
Geo-Coding
Specify additional
parking requirements
Get dynamic Parking
Information
Get free places
TISP
RDSS
Other Service Provider
End User Application
Map Data
Integrate Dynamic
Parking Data and
Map Data
Dynamic Parking
Data
Specify an address
(or PT stop)
invokes
reali ze
include
precedes
use
precedes
use
provi de
use
provide
precedes
provide
i ncl ude
use
i nclude
i nclude
use
provi de

Figure 3-19: Use Case Diagram of Service 9

In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 34 of 56
3.10 In-Time Service 10 Enhanced Walking Planning
The following use-case provides routing for pedestrians based on the static and dynamic attributes of
walking map. The service can be provided by TISP based on the dynamic attributes related to
walking paths that are pulled from RDSS (figure 3-22) or RDSS itself provides walking routing and
then this service is a subset of service 17 multi-modal journey routing.

RDSS
TISP
End User Service
getRoute
device
End User Device
Road Data
Walking Planning Service
Routing Application
(Walking Information)
Dynami c Walki ng Data
Road Data Stati c Walki ng Data

Figure 3-20: Service Chain for Enhanced Walking Planning

1. This service is initiated in the end-user application, when end-user asks for multi-modal
routing from point A to B (service 17). The generated multi-modal route most probably
includes walking part.
2.
a. When walking is a part of the selected journey, TISP asks RDSS by interface
WFS:getRoute for provision of walking route.
b. Or TISP asks for dynamic walking attributes related to the selected map area
3. Based on the request the RDSS provides the dynamic data for walking or provides the
walking route as a subset of service 17.

In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 35 of 56
3.10.1 RDSS Response-high level
This information is related to the specific implementation in the 6 In-Time cities. It does not
constitute a specification for In-Time. The complete specification can be found in D3.2.1.
This service is a part of Service 17 Multi-Modal Journey Planning, where Enhanced Walking
Planning is a part of multi-modal routing information.
With respect to this isolated service, high-level requirements for dynamic walking are required from
RDSS:
Starting point and destination point of walking
Walking instructions / navigation via waypoints
o Lat/Lon position in WGS 84
o Not Located on topological nodes
o Matched to dataset
o Ideally in the centre of a segment
Time duration of walking stage
ETA (Estimated Time of Arrival) on destination (including starting time and arrival time)
Periodical update on walking conditions

3.10.2 Use case diagram
The following Use case diagram illustrates the interaction between the end user, the TISP, the RDSS
with a highlight on the functionalities provided by each In-Time service. It is a reference way of
representing the working principles of the user interaction with the In-Time system.
The definition is based on the analysis in D2.4.1

In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 36 of 56
End User
Specifies Origin and
Destination
Interactive selection
on map
Enter Specific
Walking Planning
Criteria
Specify Obstacles to
Avoid
Get Walking planning
information
Get disturbancies
information
Get alternatives
Specify preferences
and requirements
TISP
End User Application
RDSS
Other Service Provider
Map Data
Walking data
Integrate Walking
data and map data
Calculate Walking
Route
Geo-Coding
Specify an address
(or PT stop)
provi de
i ncl ude
use
precedes
real i ze
i ncl ude
i ncl ude
i ncl ude
use
precedes
use
use
provi de
provi de
provi de
i nvokes
provi de
i ncl ude
i ncl ude
i ncl ude i ncl ude
use

Figure 3-21: Use Case Diagram of Service 10


3.11 In-Time Service 11 Dynamic Cycling Planning
The following use-case provides routing for cyclist based on the static and dynamic attributes of
walking map. The service can be provided by TISP based on the dynamic attributes related to
cycling paths that are pulled from RDSS (figure 3-24) or RDSS provides cycling routing itself and
then this service is a subset of service 17 multi-modal journey routing.



In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 37 of 56
RDSS
TISP
End User Service
getRoute
devi ce
End User Device
Road Data
Cycling Planning Service
Routing Application
(Cycling Information)
Dynami c Cycl i ng Data
Road Data
Cycl i ng Data

Figure 3-22: Service Chain for Dynamic Cycling Planning

1. This service is initiated in the end-user application, when end-user asks for multi-modal
routing from point A to B. The generated multi-modal route most may also include cycling
part.
2.
a. When cycling is a part of the selected journey, TISP asks RDSS by interface
WFS:getRoute for provision of cycling route.
b. TISP ask for dynamic cycling attributes related to the selected map area
3. Based on the request RDSS provides the dynamic data for cycling or provides the cycling
route as a subset of service 17.


3.11.1 RDSS Response-high level
This information is related to the specific implementation in the 6 In-Time cities. It does not
constitute a specification for In-Time. The complete specification can be found in D3.2.1.
This service is a part of Service 17 Multi-Modal Journey Planning, where Dynamic Cycling Planning
is a part of multi-modal routing information.
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 38 of 56
With respect to this isolated service, high-level requirements for dynamic cycling are required from
RDSS:
Starting point and destination point of cycling
Cycling instructions / navigation via waypoints
o Lat/Lon position in WGS 84
o Not Located on topological nodes
o Matched to dataset
o Ideally in the centre of a segment
Time duration of cycling stage
ETA (Estimated Time of Arrival) on destination (including starting time and arrival time)
Periodical update on cycling path conditions

3.11.2 Use case diagram
The following Use case diagram illustrates the interaction between the end user, the TISP, the RDSS
with a highlight on the functionalities provided by each In-Time service. It is a reference way of
representing the working principles of the user interaction with the In-Time system.
The definition is based on the analysis in D2.4.1

In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 39 of 56
End User
Specifies Origin and
Destination
Interactive selection
on map
Enter Specific
Cycling Planning
Criteria
Specify Obstacles to
Avoid
Get Cycling planning
information
Get disturbancies
information
Get alternatives
Specify route
charakteristics
TISP
End User Application
RDSS
Other Service Provider
Map Data
Cycling data
Integrate Cycling
data and map data
Calculate Cycling
Route
Geo-Coding
Specify an address
(or PT stop)
use
use
precedes
precedes
incl ude
i ncl ude
i ncl ude
i ncl ude
provi de
provide
provide
provi de
use
use
provi de
i ncl ude
incl ude
use
include
i nvokes
real ize

Figure 3-23: Use Case Diagram of Service 11

3.12 In-Time Service 12 Dynamic Freight Traffic Information
The following use-case describes a request from the end-user application that is associated with the
provision of a route enhanced by the dynamic features related to the freight traffic. The generated
route complies with an input such as vehicles weight, dimension and goods character. The dynamic
freight information is either pulled from RDSS or RDSS provides routing itself. The RDSS provides
dynamic freight information via the routing service, the parking service and the road traffic
information services. This service is then mainly a subset of service 17 multi-modal journey routing.


In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 40 of 56
RDSS
TISP
End User Service
WFS:
getFrei ghtRoute
WFS: getTraffi cDynami cData
WFS: getStati cPOIData
device
End User Device
Road Data
Freight Information Service
Routing Application
(Freight Information)
Dynamic Frei ght Data
POI Data Service
(static)
WFS
Stati c POI Informati on Data
Traffic Data Service
(dynamic) WFS
Dynami c Traffi c Data

Figure 3-24: Service Chain for Dynamic Freight Traffic Information

1. This service is initiated in the end-user application, when end-user asks for multi-modal
routing from point A to B. The generated multi-modal route includes optimized routing for
commercial vehicles (trucks) based on optional information (e.g. vehicle characteristics)
provided in the request.
2.
a. When freight info is a part of the selected journey, TISP asks the RDSS by interface
WFS:getFreightRoute for provision of freight route (part of service 17).
b. TISP asks the RDSS for dynamic freight attributes related to the selected map area
through getTrafficDynamicData request.
3. Based on the request the RDSS either provides Dynamic Freight data or provides vehicle
journey routing as subset of service 17.


In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 41 of 56
3.12.1 RDSS Response-high level
This information is related to the specific implementation in the 6 In-Time cities. It does not
constitute a specification for In-Time. The complete specification can be found in D3.2.1.
Features like travel times, fuel consumption and emission shall be included in the reply. This
information could be filtered, and is based on, the information related to Vehicle Characteristics.
This service is a part of Service 17 Multi-Modal Journey Planning, where Dynamic Freight
Information is a part of multi-modal routing information.
With respect to this isolated service, high-level requirements for dynamic freight information are
required from RDSS:
Starting point and destination point of route
Routing instructions / navigation via waypoints or Location Reference
o Lat/Lon position in WGS 84
o Not Located on topological nodes
o Matched to dataset
o Ideally in the centre of a segment
ETA (Estimated time of arrival) on destination of stage

3.12.2 Use case diagram
The following Use case diagram illustrates the interaction between the end user, the TISP, the RDSS
with a highlight on the functionalities provided by each In-Time service. It is a reference way of
representing the working principles of the user interaction with the In-Time system.
The definition is based on the analysis in D2.4.1
The following use case illustrates the case, when the journey routing for freight traffic information is
calculated on the RDSS site.

In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 42 of 56
End User
Specifies an area
Specifies additional
criterias
Specify period of
validity
Get specialized
Freight Traffic
Information
Speed, traffic
volume, traffic
density
Fuel/energy
consumption
Restrictions
Loading Zones
Other Service Provider
RDSS
TISP
End User Application
Map Data
Dynamic Road Traffic
Data
Freight Traffic
Specific Data
Integrate Dynamic
Freight Information
Interactive selection
on map
Specify an address
(or PTstop)
Geo-Coding
Specify vehicles and
loads characteristics
precedes
i ncl ude
precedes
i ncl ude
i nvokes
invokes
i nvokes
provi de
invokes
provide
provi de
provi de
provi de
use
real i ze
use
use
i ncl ude
real i ze
i ncl ude
use
i ncl ude
use
include

Figure 3-25: Use Case Diagram of Service 12


3.13 In-Time Service 13 Dynamic POI Information
The following use-case provides static as well as dynamic POI information. Dynamic content of POI
is mostly related to the dynamic parking information. The parking information is provided by RDSS.
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 43 of 56
RDSS
TISP
End User Service
WFS:
getDynami cPOIInformati on
devi ce
End User Device
Road Data
Dynamic POI information
Dynami c POI Data
POI Information
(dynamic)
WFS

Figure 3-26: Service Chain for Dynamic POI Information

1. This service is initiated in end-user application, when the end-user wants to check dynamic
content of POI (e.g. free parking spaces available in a parking facility).
2. TISP ask the RDSS server to provide dynamic parking information from his
GetDynamicPOIInformation.
3. Based on this request, RDSS provides to the TISP dynamic parking information to the
selected parking facility.

3.13.1 RDSS Response-high level
This information is related to the specific implementation in the 6 In-Time cities. It does not
constitute a specification for In-Time. The complete specification can be found in D3.2.1.
RDSS will provide static information to POI:
POI Information
POI Category
POI Entrances (which were specifically indicated by GEO)

In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 44 of 56
In particular useful information that must be provided with respect to the dynamic parking information
by the RDSS to the TISPs is:
Opening Times (opening, closing time per day)
Tariffs (fee per time period and day)

3.13.2 Use case diagram
The following Use case diagram illustrates the interaction between the end user, the TISP, the RDSS
with a highlight on the functionalities provided by each In-Time service. It is a reference way of
representing the working principles of the user interaction with the In-Time system.
The definition is based on the analysis in D2.4.1

End User
Specify an address
(or PT stop)
Specifies an area
Specifies a point
get GPS position
Geo-Coding
Interactive selection
on map
Specify category of
POI
Get POI Information
RDSS
TISP
Other Service Provider
End User Application
POI Information Map Data
Integrate POI
Information and Map
Data
i nvokes
real i ze
use use
precedes
use
provide provi de
precedes
provi de
precedes
provi de
i ncl ude
i ncl ude
use
i ncl ude
use
provi de

Figure 3-27 Use Case Diagram of Service 13


In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 45 of 56
3.14 In-Time Service 14 Dynamic Traffic Event Information
This use-case provides information about an event (concert, trade fair etc...) which does not happen
directly on the road, but which may influence the behaviour of drivers and hence the characteristics
of the traffic flow. The RDSS gives information on temporary established parking facilities or/and
temporary re-routed public transport lines.
RDSS
TISP
End User Service WFS:
getDynami cTraffi cData
WFS:
getDynami cEventData
devi ce
End User Device
Road Data
Traffic Event Information Service
Dynami c Traffi c Data
Traffic Data Service
(dynamic)
WFS
Non-Road Informati on Data
Event Data Service
(dynamic)
WFS

Figure 3-28: Service Chain for Dynamic Traffic Event Information

1. This service is initiated in use-cases when the end-user asks TISP for temporary-changed
traffic condition caused by an event in the map.
2. Based on the TISP request, RDSS provides to the TISP dynamic road information through
WFS interface getDynamicRoadData and temporary dynamic information that are closely
related with an event through getDynamicEventData interface.

3.14.1 RDSS Response-high level
This information is related to the specific implementation in the 6 In-Time cities. It does not
constitute a specification for In-Time. The complete specification can be found in D3.2.1.
The service is an extension of the services related to dynamic road information (Service 2 and
service 6). The extension includes:
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 46 of 56
Transit Information- characterises the availability of transit services and information relating
to their departures. This is limited to those transit services which are of direct relevance to
road users, e.g. connecting rail or ferry services.
Service Disruption (information about fuel shortage, service area closed, some commercial
service closed etc.)
Dynamic Parking Information which supplies information on temporary car parks.

3.14.2 Use case diagram
The following Use case diagram illustrates the interaction between the end user, the TISP, the RDSS
with a highlight on the functionalities provided by each In-Time service. It is a reference way of
representing the working principles of the user interaction with the In-Time system.
The definition is based on the analysis in D2.4.1

In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 47 of 56
End User
Specify Event
Specifies additional
criterias
Specify period of
validity
Get event
Information
Get static Information
Get Dynamic
Information
Parking locations
Shuttle services
Traffic situation
Programme
Event Location
RDSS
TISP
Other Service Provider
End User Application
Dynamic Event
Information
Map Data
Static Event
Information
Integrate Event
Information and Map
Data
i ncl ude
use
use
precedes precedes
incl ude
i ncl ude
i ncl ude
i ncl ude
i ncl ude
incl ude
i ncl ude
use
provi de
provi de
provi de
provi de
provi de
i nvokes i nvokes
incl ude

Figure 3-29: Use Case Diagram of Service 14


3.15 In-Time Service 15 Dynamic Weather Information
This use case provides dynamic weather information for specific roads, road segments (links), route
or administrative area. The weather information shall be regularly updated in certain intervals. The
weather information for the whole region is periodically sent from the RDSS to the TISP. The TISP
then provides weather information to end-users as additional information related to specified route or
area.

In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 48 of 56
RDSS
TISP
End User Service
WFS:
getDynami cTraffi cData
WFS:
getDynami cWeatherData
devi ce
End User Device
Road Data
Weather Information Service
Dynami c Traffi c Data
Traffic Data Service
(dynamic)
WFS
Dynami c Weather Informati on Data
Weather Data Service
(dynamic)
WFS

Figure 3-30 Service Chain for Dynamic Weather information

1. This service is initiated in use-cases when the end-user asks for weather conditions related
to certain route or to a point or area in the map.
2. TISP asks in periodically defined intervals the RDSS for providing weather update from all
service covered areas.
3. Based on these requests, the RDSS provides continuously the TISP current weather
information from covered areas through WFS interface getDynamicWeatherData.

3.15.1 RDSS Response-high level
This information is related to the specific implementation in the 6 In-Time cities. It does not
constitute a specification for In-Time. The complete specification can be found in D3.2.1.
The service is an extension of the data structure related to dynamic road information (Service 2 and
service 6). This extension includes:
Various weather conditions (ice, heavy rain, snowfall, etc...)
Location reference (Assignment of various weather condition to road segments )

In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 49 of 56
3.15.2 Use case diagram
The following Use case diagram illustrates the interaction between the end user, the TISP, the RDSS
with a highlight on the functionalities provided by each In-Time service. It is a reference way of
representing the working principles of the user interaction with the In-Time system.
The definition is based on the analysis in D2.4.1

End User
Specifies an area
Specifies additional
criterias
Specify period of
validity
Get Weather
information
Get current weather
situation
Get weather
forecasts
RDSS
TISP
Other Service Provider
Interactive selection
on map
End User Application
Map Data
Weather Data
Integrate Weather
Data and map Data
Specify an address
(or PT stop)
Geo-Coding
Specifies a point
provide
precedes
incl ude
i nclude
use
use
precedes
use
incl ude
provi de
precedes
provide
provi de
i nvokes
i ncl ude
i ncl ude
include
use
provi de

Figure 3-31: Use Case Diagram of Service 15

3.16 In-Time Service 16 Static and Dynamic Flight Information
This service provides static and dynamic information on flights such as departure time, flight number
or Air Company. The information is provided by the RDSS.
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 50 of 56
RDSS
TISP
End User Service
WFS:getFl i ghtData
devi ce
End User Device
Road Data
Flight Information Service
Stati c Fl i ght Data
Dynami c Fl i ght
Data
Flight Data Service
(static and dynamic)
WFS

Figure 3-32: Service Chain for Static and Dynamic Flight Information

1. This service is initiated in use-cases when the end-user asks TISP for static and dynamic
flight information.
2. Based on the request parameters from the TISP, the RDSS provides to the TISP static or
dynamic flight information through WFS interface getFlightData.

3.16.1 RDSS Response-high level
This information is related to the specific implementation in the 6 In-Time cities. It does not
constitute a specification for In-Time. The complete specification can be found in D3.2.1.
The response provided by the RDSS to the TISPs is a list of flights:
Airports (IATA Code, Name)
Airlines (IATA Code, Name)
Flight numbers (IATA code)
Timetables (arrival time departure time) for static as well as for dynamic data



In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 51 of 56
3.16.2 Use case diagram
The following Use case diagram illustrates the interaction between the end user, the TISP, the RDSS
with a highlight on the functionalities provided by each In-Time service. It is a reference way of
representing the working principles of the user interaction with the In-Time system.
The definition is based on the analysis in D2.4.1

End User
Specify Departure
and Arrival Places
Specify Additional
Parameters
Specify Departure
and Arrival Dates
Specify Departure
and Arrival Times
Specify Flight
Numbers
Get Flight Information
Get Time Schedule
Get real-time
arrival/departures
Integrate Flight
Information
TISP
Flight Information
RDSS
End User Application
precedes
incl ude
include
incl ude
use
incl ude
precedes
incl ude
provi de
i nvokes
provi de
i nvokes
invokes
precedes

Figure 3-33: Use Case Diagram of Service 16

3.17 In-Time Service 17 Comparative Dynamic Multi Modal Journey
Planning
This use case is in fact the only end-user service delivering routing information offering
simultaneously all travel choices at once. The generation of the multi-modal route can be realized
several ways. The routing algorithm for public transport routing is proposed to be at the RDSS server
and TISP receives the complete PT journey routing. The routing service for vehicles and
pedestrians can be provided either by the RDSS or by the TISP as described in relevant sub-
chapters. The complete multi-modal journey may be compiled by the RDSS and provided as a whole
journey to TISP, or TISP gets separate routes for every stage of the journey from RDSS and
generates the whole multi-modal journey at its side. Both possibilities are depicted in the Figure
3-34 and Figure 3-35 respectively.
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 52 of 56
Dynamic Multi-Modal Planning Service
RDSS
TISP
End User Service
getMul ti Modal Route
Road Data
devi ce
End User Device
Thi s di agram represent
a TISP who provi des a
mul ti -modal j ourney
i nformati on comi ng
di rectl y from the RDSS
Multi-modal Journey
Planning
Application
getMul ti Modal Route
Cycl i ng Informati on
Indi vi dual Traffi c Data
Wal ki ng Informati on
Dynami c Publ i c Transport Data

Figure 3-34: Service Chain for Dynamic Multi-modal Journey Routing- RDSS route generation
In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 53 of 56
RDSS
TISP
End User Service
getCycl i ngRoute
getRoute
getWal ki ngRoute
getPTRoute
Road Data
devi ce
End User Device
Dynamic Cycling Planning Service
Cycling Planning
Applpication
getCycli ngRoute
Cycl i ng Information
Dynamic Routing Service (Road Traffic)
Routing Application
(Road Traffic)
getRoute
Indi vidual Traffi c Data
Dynamic Walking Planning Service
Walking Planning
Application
getWal kingRoute Walki ng Informati on
Public Transport Journey Planning Service
Public Transport
Journey Planning
Application
getPTRoute
Dynami c Publ i c Transport Data
Thi s di agram represent
a TISP who wants to
provi de i ts own
mul ti -modal route
based on the
i nformati on comi ng
from the RDSS
regardi ng each single
mode

Figure 3-35: Service Chain for Dynamic Multi-modal Journey Routing- TISP route generation

1. This service is initiated when the end-user asks TISP for multi-modal routing from selected
starting point to the selected destination.
2. The TISP asks the RDSS to provide multi-modal route or selected stages of the multi-modal
journey.
3. Based on this request, RDSS provides to the TISP either complete routing including all
modes of travel or provides only separated routes that are used by TISP as building blocks
for its complete multi-modal route generation.



In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 54 of 56
3.17.1 RDSS Response-high level
This information is related to the specific implementation in the 6 In-Time cities. It does not
constitute a specification for In-Time. The complete specification can be found in D3.2.1.

Useful information that must be provided by the RDSS to the TISPs is:
ETA (estimated time of arrival) on destination
Number of modes used
Number of interchanges
Route identifier (from TISP user session)
Related information to each mode of transport is:
ETA (estimated time of arrival) on destination
Name of a Station (departure, arrival)
Location of a station (lat/lon, OPEN LR)
Walking instructions

3.17.2 Use case diagram
The following Use case diagram illustrates the interaction between the end user, the TISP, the RDSS
with a highlight on the functionalities provided by each In-Time service. It is a reference way of
representing the working principles of the user interaction with the In-Time system.
The definition is based on the analysis in D2.4.1

In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 55 of 56
End User
Specifies Origin and
Destination
Interactive selection
on map
Geo-Coding
Specify Preferences
(Cost, Distance,Road
Types)
Specifies additional
criterias
Specify Start and
Arrival times
Specify Via Points
Specify preferred
means of transport
Specify maximum
number of changes
Get Multi-Modal route
information
means of transport
number of changes
special services
Costs/prices
restrictions
fuel/energy
consumption
parking facilities
Multimodal Route Planner
TISP
RDSS
dynamic/static route
data
Get Route Details
End User Application
Map Data
Other Service Provider
Specify an address
(or PT stop)
precedes
i ncl ude
i ncl ude
precedes
use
i ncl ude
i ncl ude i ncl ude
i ncl ude
i ncl ude
i ncl ude
i ncl ude
i ncl ude
i ncl ude
provi de
use
i ncl ude
i ncl ude
i ncl ude
i ncl ude
i ncl ude
provi de
provi de
provi de
use
provi de
i nvokes use

Figure 3-36: Use Case Diagram of Service 17







In-Time
Pilot Type B

D3.1.2 UML schemes finalized Specification V1.0
Page 56 of 56
4 Conclusion
In previous sub-chapters every In-Time service was presented in terms of use-case and deployment
diagrams as well as high-level requirements that are expected from RDSS as response to each TISP
requests. This shall help to understand how each service can be realized. It has to be noted that
below mentioned services that include the routing function i.e.:
service 5 (static walking information)
service 10 (enhanced walking planning),
service 11 (dynamic cycling planning),
service 12 (dynamic freight traffic information)

may have the route generation either at the RDSS side (TISP receives a set of waypoints for every
net segment and arrival times), or TISP will generate routing itself based on the provided dynamic
attributes, that enhance the static features of the road network (speed profiles, work closures, cycle
paths, etc.). These dynamic features may be provided for passenger car and truck routing as well as
for pedestrian or bicycle routing.