Its Multimodal Servis Eu

Embed Size (px)

Citation preview

  • 8/11/2019 Its Multimodal Servis Eu

    1/56

    In-TimeIntelligent 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 theEuropean Commission, DG Information Society and Media

    in the CIP-ICT-PSP-2008-2 Programme

  • 8/11/2019 Its Multimodal Servis Eu

    2/56

    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)

  • 8/11/2019 Its Multimodal Servis Eu

    3/56

    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 changes0.1 19/02/10 Jan Borkovec TOC0.2 18/03/10 Michele Masnata

    Marco GarrComments and suggestions to thedocument structure and concept.

    Provision of use-case diagrams for thedocument.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-leveldefinitions of feature types required foreach use-case.

    0.5 1/04/10 Michele Masnata Revision of the document. Theintroductive chapters Scope of thedocument and Methodology modifiedand extended.

    0.6 7/04/10 Karl Schedler Minor correction and update of the

    service 15 Dynamic Weatherinformation.

    0.7 14/04/10 Francesco Alesiani Minor correction and update of theservice 12 Dynamic FreightInformation.

    0.8 31/04/10 Rainer RehbergerHannes Koller

    During the internal review these partsof the documents were proposed to bemodified: Static road informationservice, Static and Dynamic flightinformation service.

    0.9 04/05/10 Jan Borkovec Minor corrections and updates basedon internal review process.

    1.0 07/05/10 Jan Borkovec Correction of typos. The tabledescribing the history of the documentwas updated. Final release version.

  • 8/11/2019 Its Multimodal Servis Eu

    4/56

    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 andCoordination 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 ArsenalGes.m.b.H. ARS AT

    21 Memex Srl MEM IT

    22 Austro Control - sterreichische Gesellschaft frZivilluftfahrt

    ACG AT

  • 8/11/2019 Its Multimodal Servis Eu

    5/56

    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

  • 8/11/2019 Its Multimodal Servis Eu

    6/56

    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

  • 8/11/2019 Its Multimodal Servis Eu

    7/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

  • 8/11/2019 Its Multimodal Servis Eu

    8/56

  • 8/11/2019 Its Multimodal Servis Eu

    9/56

    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 thisdocument 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 areference specification which describes common functional blocks and analyzes common dataelements and processes as well as the expected information flow for each of the In-Time servicesdefined in WP2 (Deliverable D2.4.1). This will enable a cross-check of functionalities and shouldensure consistency and homogeneity in the implementation. The present analysis and specificationmake use of UML components diagrams showing, for each use case, the interaction of data andservices in the In-Time value chain in terms of end-user, TISP and RDSS components and their highlevel interfaces. Use case diagrams are also defined to have a user-oriented view of the informationflow.

    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 (describingfunctional 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 thepoint of view of the end user service)

    b) A high-level definition of features (pieces of information) to be supported by the In-TimeCommonly Agreed Interface to enable the implementation of each of the 17 In-Timeservices.

    Point b) refers to an activity which represents a selection of the necessary sub-set of data andservices from the complete and rather extended In-Time specification which make provision of a verydetailed 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 featurespecification -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 ofTISPs requirements and pilot specific needs and it was concluded by putting together andharmonizing every detected feature.

    This activity has to be considered actually the very first (high-level) step of the implementationprocess 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 isdriven by a different approach and background.

    The high-level feature specification is limited to the specific requirements of the six In-Time pilotsites. For this reason whereas functional block definitions (UML component diagrams) are reflectingthe organization and connection of system components and this is not the result of specific pilotchoices and can be considered as a reference design indication, the high-level specification of thenecessary features constitutes only a reference for the present In-Time project implementationbecause it has been defined by harmonizing single and specific requirements. This shall constituteonly an example of what followers cites have to do in order to start an In-Time implementation from

  • 8/11/2019 Its Multimodal Servis Eu

    10/56

    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 aspecific implementation in following cities, is defined in Deliverable D3.2.1.

    The High-level identification of the necessary CAI features (also called minimum requirements ofthe CAI) is the driver for the definition of that part of the complete In-Time specification (defined inD3.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 DeliverableD3.4.1

  • 8/11/2019 Its Multimodal Servis Eu

    11/56

    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, Servicescan be distinguished according to where the In-Time service is generated. There are services thatneed to be created at RDSS side. These services do not include journey routing that can otherwisebe done also by TISP (except for Public Transport Journey Routing1):

    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 journeyrouting 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

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

  • 8/11/2019 Its Multimodal Servis Eu

    12/56

    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 everynetwork segment, arrival times and changing points for public transport), or TISP will generaterouting itself based on the provided dynamic attributes, that modify the static features of roadnetwork (speed profiles, work closures, cycle path, walking obstacles, etc..). These dynamic featuresmay 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 Deploymentdiagrams and Use case diagrams modelled in Enterprise Architect software. Use-case diagramsshow the relationship and interactions between actors End-user, TISP, RDSS and Other serviceprovider. Deployment diagrams provide higher level of abstraction than class diagrams, becausecomponent may be implemented by one or more classes. This is the reason, why componentdiagrams were selected in this high-level UML model, because this representation avoids theproblem of describing different subset of classes among pilot cities. This allows having commondiagrams for every pilot, where RDSS component is a Data service- it basically provides In-Timedata 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 RDSSprovides a service or data to TISP. Therefore for every use-case, there is a remark that defines thepossibilities of the service provision.

    UML diagrams presented in this report can be assumed to be applicable to (or constitute a referencefor) every pilot city, even followers cities, as they are the result of a common analysis based on theaccepted In-Time service definition.

    Besides these models which describes the In-Time system from the functional point of view as wellas 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 featuresnecessary for the implementation of the services collected starting from RDSSs and TISPsrequirements. This lead to a harmonized and common specification of high-level requirements whichwill be reflected, in a more detailed phase of the implementation activity, in a selection of the subsetof the In-Time data model suitable for the concrete specification and realization of the necessarydata 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 detailedsubset 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 UMLdiagrams 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 inDeliverable D3.2.1.

  • 8/11/2019 Its Multimodal Servis Eu

    13/56

    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 theprovision of a static road network. The static road network can be either provided by the TISP itselfby allowing installation of digital maps in the end-user PDAs (figure 3-1) or will be provided via WFSinterface from the RDSS (figure 3-2).

    End User Service

    End User

    Application

    TISP

    End User ServiceStatic Road map

    Figure 3-1: Service chain for Static Road Information

    RDSS

    TISP

    End User ServiceWFS:getStaticRoadData

    device

    End User Device

    Road traffic information servic e

    Road DataRoad information

    (static)

    WFS

    Figure 3-2: Service chain for Static Road Information

  • 8/11/2019 Its Multimodal Servis Eu

    14/56

    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 Bor 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 maybe required to transfer from the RDSS to the TISP. Performing this transfer every time a routing isrequested will be very inefficient. A more efficient strategy would be for the TISP to keep a copy ofthe 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 linksandRoad 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 RDSSwith a highlight on the functionalities provided by each In-Time service. It is a reference way ofrepresenting the working principles of the user interaction with the In-Time system.

    The definition is based on the analysis in D2.4.1

  • 8/11/2019 Its Multimodal Servis Eu

    15/56

    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 selection

    on map

    Get static information

    (point or area)

    Get speed limit

    Get Roa d Type

    Get Route

    Get Restrictionsget GPS position

    Specifies Origin and

    Destination

    Get static information

    (road)

    Get Distance

    Specifies an area

    RDSS

    Road Network data

    Integrate Road

    network and map

    information

    TISP

    End User A pplication

    Other Service Provider

    Map Data

    Get Static Road

    traffic Information

    Specify an address

    (or PT stop)

    include

    include

    include

    include

    include

    precedes

    include

    provide

    use

    precedes

    include

    include

    use

    include

    include

    provide

    provide

    include

    use

    precedes

    include

    provide

    use

    realize

    use

    provide

    include

    Figure 3-3: Use case Diagram of Service 1

    3.2 In-Time Service 2 Dynamic Road Traffic Information on highernetwork (TMC quality)

    In the following use-case the RDSS provides instant (or future) description of road network trafficcondition. This may include temporary road closures, information about traffic levels or events suchare car accidents. The location reference methodology enables to assign all traffic events to theexact location on the road network. Provision of this service is necessary for the dynamic vehiclejourney routing because based on this service TISP provides vehicle routing as a subset of service17. Another option is that the RDSS not only provides dynamic traffic information as standalonedata, but generates dynamic vehicle routing itself by means of provision of waypoints for navigationto the TISP.

  • 8/11/2019 Its Multimodal Servis Eu

    16/56

    In-Time

    Pilot Type B

    D3.1.2 UML schemes finalized Specification V1.0

    Page 16 of 56

    RDSS

    TISP

    End User ServiceWFS:

    getDynamicRoadTraffic

    device

    End User Dev ice

    Road Data

    Dynamic road traffic information

    Dynamic Road Traffic

    Data Road Traffic Data

    Serv ice (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 frompoint 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 currentstate 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 includetemporary changes in static road network i.e. road closures and road works and dynamic trafficlevels 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..)

  • 8/11/2019 Its Multimodal Servis Eu

    17/56

    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 RDSSwith a highlight on the functionalities provided by each In-Time service. It is a reference way ofrepresenting 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 additionalcriterias Get Dynamic Traffic

    Information

    Specify type of

    dynamic Information

    Specify type of

    disturbance

    Specify period of

    validity

    Get disturbance

    notifications

    Get camera pictures

    RDSSTISP

    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

    Destinationuse

    includeinclude

    precedes

    include

    include

    realize

    use

    use

    include

    provide

    provide

    provideprovide

    invokes

    include

    includeinclude

    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 roadmap. For every parking facility additional useful information is provided. Static parking information isprovided by the RDSS.

  • 8/11/2019 Its Multimodal Servis Eu

    18/56

    In-Time

    Pilot Type B

    D3.1.2 UML schemes finalized Specification V1.0

    Page 18 of 56

    RDSS

    TISP

    End User ServiceWFS:

    getStaticParkingInformation

    device

    End User Device

    Road Data

    Static parking information

    Static parking dataParking 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 forPark&Ride instructions.

    2. TISP asks the RDSS server to provide static parking information from hisGetStaticParkingData 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)

  • 8/11/2019 Its Multimodal Servis Eu

    19/56

    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 therequirements coming from the TISP. It must be underlined that some other basic static informationthat maybe could be provided easily by the RDSS, e.g. Opening Times, are not taken into accountin 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 RDSSwith a highlight on the functionalities provided by each In-Time service. It is a reference way ofrepresenting 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 requirementsGet Static parking

    information

    Other Service Provider

    RDSS

    TISPMap Data

    Integrate Map Data

    and Parking Data

    Provide Static

    Parking Data

    End User Application

    Specify an address

    (or PT stop)

    invokesrealize

    precedes

    use

    precedes

    use

    provide

    provide

    use

    provide

    precedes

    provideinclude

    use

    include

    include

    use

    provide

    Figure 3-7: Use Case Diagram of Service 3

  • 8/11/2019 Its Multimodal Servis Eu

    20/56

  • 8/11/2019 Its Multimodal Servis Eu

    21/56

    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. Operatoroperates a Linewhich has a Journey (or aServiceDescription) describing the sequence of Stop Points that will be visited providing also anarrival 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 RDSSwith a highlight on the functionalities provided by each In-Time service. It is a reference way ofrepresenting the working principles of the user interaction with the In-Time system.

    The definition is based on the analysis in D2.4.1

  • 8/11/2019 Its Multimodal Servis Eu

    22/56

    In-Time

    Pilot Type B

    D3.1.2 UML schemes finalized Specification V1.0

    Page 22 of 56

    Geo-Coding

    End UserSpecify Start time

    Specify

    Mode/Service/Operator

    Specify Additional

    ParametersGet 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

    Prov ide Static PT

    Information

    Integrate PTinformation and map

    data

    include

    include

    include

    realize

    use

    precedes

    use

    precedes

    precedes

    use

    provideprovide

    provide

    invokes

    provide

    invokes

    include

    include

    include

    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 awalking 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 waypointsfor walking navigation to TISP. This routing is then part of the service 17, where simultaneous multi-modal routing is provided.

  • 8/11/2019 Its Multimodal Servis Eu

    23/56

    In-Time

    Pilot Type B

    D3.1.2 UML schemes finalized Specification V1.0

    Page 23 of 56

    RDSS

    TISP

    End User ServiceWFS:

    getStaticWalkingData

    device

    End User Device

    Road Data

    Road traffic information serv ice

    Road DataWalking information

    (static)

    WFS

    Walking 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-modalrouting from point A to B. The generated multi-modal route most probably includes walkingpart.

    2. When walking is a part of the selected journey, TISP asks the RDSS by interfaceWFS: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

  • 8/11/2019 Its Multimodal Servis Eu

    24/56

  • 8/11/2019 Its Multimodal Servis Eu

    25/56

    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 PT stop)

    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

    include

    precedes

    realize

    use

    precedes

    use

    provideuse

    provide

    precedes

    invokes

    provide

    include

    include

    include

    use

    provide

    Figure 3-11: Use Case Diagram of Service 5

    3.6 In-Time Service 6 Dynamic Road Traffic Information forsecondary road network

    In the following use-case the RDSS provides dynamic traffic info as time-variable traffic and networkfeatures that are offered to TISP for their actual routing adaptation. This is the case the RDSS is adata 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 waypointsfor navigation to TISP. Then this routing is a part of the service 17, where simultaneous multi-modalrouting is provided.

  • 8/11/2019 Its Multimodal Servis Eu

    26/56

    In-Time

    Pilot Type B

    D3.1.2 UML schemes finalized Specification V1.0

    Page 26 of 56

    RDSS

    TISP

    End User ServiceWFS:

    getDynamicRoadTraffic

    device

    End User Dev ice

    Road Data

    Dynamic road traffic information

    Dynamic Road Traffic DataRoad Traffic Data

    Serv ice (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 frompoint 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 thecurrent 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 notconstitute 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 includetemporary changes in static road network i.e. road closures and road works and dynamic trafficlevels 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.)

  • 8/11/2019 Its Multimodal Servis Eu

    27/56

    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 RDSSwith a highlight on the functionalities provided by each In-Time service. It is a reference way ofrepresenting 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

    RDSSTISP

    End User Application

    Prov ide 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

    Destinationuse

    includeinclude

    precedes

    include

    include

    realize

    use

    use

    include

    provide

    provide

    provideprovide

    invokes

    include

    includeinclude

    use

    precedes

    precedes

    precedes

    precedes

    Figure 3-13: Use Case Diagram of Service 6

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

  • 8/11/2019 Its Multimodal Servis Eu

    28/56

    In-Time

    Pilot Type B

    D3.1.2 UML schemes finalized Specification V1.0

    Page 28 of 56

    RDSS

    TISP

    End User ServiceWFS:

    getDynamicPublicTransport

    device

    End User Devic e

    Road Data

    Dynamic public transport information

    Dynamic publi c transport dataPublic 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 inselected area with corresponding dynamic arrival/departure times for PT lines. End userselects in the map desired origin or destination point and start time or arrival t ime.

    5. Based on this request, TISP asks RDSS by interface WFS:getStaticPublicTransport forprovision of the nearest PT stops according to end-user selection. The RDSS response withGPS location of PT stops possible.

    6. End-user selects the PT stop and TISP asks again RDSS by interfaceWFS: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 aperiodical 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

  • 8/11/2019 Its Multimodal Servis Eu

    29/56

    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 RDSSwith a highlight on the functionalities provided by each In-Time service. It is a reference way ofrepresenting 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 DataDynamic PT

    Information

    Integrate PT

    Information and Map

    Data

    Get Static Public

    Transport Information

    use

    use

    realize

    include

    include

    precedes

    include

    precedes

    use

    include

    provide provide

    provide

    invokes

    provide

    invokes

    include

    include

    include

    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 transportdata. The service will be provided by a set of textual instructions defining for each journey startingpoint, changing point, departure stop and travel time. The service is provided by the RDSS.

  • 8/11/2019 Its Multimodal Servis Eu

    30/56

    In-Time

    Pilot Type B

    D3.1.2 UML schemes finalized Specification V1.0

    Page 30 of 56

    RDSS

    TISP

    End User Service

    getPTRoute

    device

    End User DeviceRoad Data

    Public Transport Journey Planning Service

    Dynamic Publi c Transport DataPublic 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-modalrouting from point A to B.

    2. When public transport is a part of the selected journey (by explicit request of the user), TISPasks 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 transportRouting is a part of multi-modal routing information. The public transport journey routing is offeredas 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) forreturned solution

    Number of interchanges (via points)

    Public transport line identification (e.g. bus number)

  • 8/11/2019 Its Multimodal Servis Eu

    31/56

    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 RDSSwith 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 andDestination

    Interactive selection

    on map

    Geo-Coding

    Specify

    Mode/Service/Operator

    Specify Additional

    ParametersSpecify Start time

    Specify Via PointSpecify 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 PT Data

    Integrate PT Data and

    Map Data

    Calculate P T Route

    Specify an address

    (or PT stop) use

    include

    include

    use

    use

    include

    precedes

    include

    include

    precedes

    use

    realize

    provide

    provide

    provide

    invokes

    provide

    invokes

    include

    include

    include

    include

    use

    precedes

    realize

    Figure 3-17: Use Case Diagram of Service 8

  • 8/11/2019 Its Multimodal Servis Eu

    32/56

  • 8/11/2019 Its Multimodal Servis Eu

    33/56

    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 RDSSwith a highlight on the functionalities provided by each In-Time service. It is a reference way ofrepresenting 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

    realize

    include

    precedes

    use

    precedes

    use

    provide

    use

    provide

    precedes

    provide

    include

    use

    include

    include

    use

    provide

    Figure 3-19: Use Case Diagram of Service 9

  • 8/11/2019 Its Multimodal Servis Eu

    34/56

    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 ofwalking map. The service can be provided by TISP based on the dynamic attributes related towalking 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 Serv ice

    Routing Application

    (Walking Information)

    Dynamic Walking Data

    Road Data Static Walking 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-modalrouting from point A to B (service 17). The generated multi-modal route most probablyincludes walking part.

    2.

    a. When walking is a part of the selected journey, TISP asks RDSS by interfaceWFS: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 thewalking route as a subset of service 17.

  • 8/11/2019 Its Multimodal Servis Eu

    35/56

    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 fromRDSS:

    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 RDSSwith a highlight on the functionalities provided by each In-Time service. It is a reference way ofrepresenting the working principles of the user interaction with the In-Time system.

    The definition is based on the analysis in D2.4.1

  • 8/11/2019 Its Multimodal Servis Eu

    36/56

    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 disturbanciesinformation

    Get alternativesSpecify preferences

    and requirements

    TISP

    End User Application

    RDSS

    Other Service ProviderMap Data

    Walking data

    Integrate Walking

    data and map data

    Calculate Walking

    Route

    Geo-Coding

    Specify an address

    (or PT stop)

    provide

    include

    use

    precedes

    realize

    include

    includeinclude

    use

    precedes

    use

    use

    provide

    provide

    provide

    invokes

    provide

    includeinclude

    includeinclude

    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 ofwalking 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 andthen this service is a subset of service 17 multi-modal journey routing.

  • 8/11/2019 Its Multimodal Servis Eu

    37/56

    In-Time

    Pilot Type B

    D3.1.2 UML schemes finalized Specification V1.0

    Page 37 of 56

    RDSS

    TISP

    End User Service

    getRoute

    device

    End User Device

    Road Data

    Cycling Planning Service

    Routing Application

    (Cycling Information)

    Dynamic Cycling Data

    Road Data Cycling 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-modalrouting from point A to B. The generated multi-modal route most may also include cyclingpart.

    2.

    a. When cycling is a part of the selected journey, TISP asks RDSS by interfaceWFS: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 cyclingroute 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 Planningis a part of multi-modal routing information.

  • 8/11/2019 Its Multimodal Servis Eu

    38/56

    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 fromRDSS:

    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 RDSSwith a highlight on the functionalities provided by each In-Time service. It is a reference way ofrepresenting the working principles of the user interaction with the In-Time system.

    The definition is based on the analysis in D2.4.1

  • 8/11/2019 Its Multimodal Servis Eu

    39/56

    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 ProviderMap Data

    Cycling data

    Integrate Cycling

    data and map data

    Calculate Cycling

    Route

    Geo-Coding

    Specify an address(or PT stop)

    use

    use

    precedes

    precedes

    include

    include

    include include

    provide

    provide

    provide

    provideuse

    use

    provide

    include

    include

    use

    include

    invokes

    realize

    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 theprovision of a route enhanced by the dynamic features related to the freight traffic. The generatedroute complies with an input such as vehicles weight, dimension and goods character. The dynamicfreight 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 trafficinformation services. This service is then mainly a subset of service 17 multi-modal journey routing.

  • 8/11/2019 Its Multimodal Servis Eu

    40/56

    In-Time

    Pilot Type B

    D3.1.2 UML schemes finalized Specification V1.0

    Page 40 of 56

    RDSS

    TISP

    End User Serv ice

    WFS:

    getFreightRoute

    WFS: getT rafficDynamicData

    WFS: getStaticPOIData

    device

    End User Dev ice

    Road DataFreight Information Service

    Routing Application

    (Freight Information)

    Dynamic Freight Data

    POI Data Service

    (static)WFS

    Static POI Information Data

    Traffic Data Serv ice

    (dynamic) WFS

    Dynamic Traffic 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-modalrouting from point A to B. The generated multi-modal route includes optimized routing forcommercial 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 interfaceWFS:getFreightRoute for provision of freight route (part of service 17).

    b. TISP asks the RDSS for dynamic freight attributes related to the selected map areathrough getTrafficDynamicData request.

    3. Based on the request the RDSS either provides Dynamic Freight data or provides vehiclejourney routing as subset of service 17.

  • 8/11/2019 Its Multimodal Servis Eu

    41/56

    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 FreightInformation is a part of multi-modal routing information.

    With respect to this isolated service, high-level requirements for dynamic freight information arerequired 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 RDSSwith a highlight on the functionalities provided by each In-Time service. It is a reference way ofrepresenting 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 iscalculated on the RDSS site.

  • 8/11/2019 Its Multimodal Servis Eu

    42/56

    In-Time

    Pilot Type B

    D3.1.2 UML schemes finalized Specification V1.0

    Page 42 of 56

    End UserSpecifies an area

    Specifies additional

    criterias

    Specify period of

    validity

    Get specialized

    Freight Traffic

    Information

    Speed, traffic

    v olume, 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 DataIntegrate Dynamic

    Freight InformationInteractive selection

    on map

    Specify an address

    (or PT stop)

    Geo-Coding

    Specify vehicle s and

    loads characteristics

    precedes

    include

    precedes

    include

    invokes invokes

    invokes

    provide

    invokes

    provide

    provide

    provide

    provide

    use

    realize

    use

    use

    include

    realize

    include

    use

    include

    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 POIis mostly related to the dynamic parking information. The parking information is provided by RDSS.

  • 8/11/2019 Its Multimodal Servis Eu

    43/56

    In-Time

    Pilot Type B

    D3.1.2 UML schemes finalized Specification V1.0

    Page 43 of 56

    RDSS

    TISP

    End User ServiceWFS:

    getDynamicPOIInformation

    device

    End User Device

    Road Data

    Dynamic POI information

    Dynamic POI DataPOI 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 dynamiccontent of POI (e.g. free parking spaces available in a parking facility).

    2. TISP ask the RDSS server to provide dynamic parking information from hisGetDynamicPOIInformation.

    3. Based on this request, RDSS provides to the TISP dynamic parking information to theselected 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)

  • 8/11/2019 Its Multimodal Servis Eu

    44/56

    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 informationby 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 RDSSwith a highlight on the functionalities provided by each In-Time service. It is a reference way ofrepresenting 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

    POIGet POI Information

    RDSS

    TISP

    Other Serv ice Provider

    End User Application

    POI InformationMap Data

    Integrate POI

    Information and Map

    Data

    invokes

    realize

    useuse

    precedes

    use

    p ro vid e p ro vi de

    precedes

    provide

    precedes

    provide

    include

    include

    use

    include

    use

    provide

    Figure 3-27 Use Case Diagram of Service 13

  • 8/11/2019 Its Multimodal Servis Eu

    45/56

    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 happendirectly 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.

    RDSSTISP

    End User ServiceWFS:

    getDynamicTrafficData

    WFS:

    getDynamicEventData

    device

    End User Dev ice

    Road DataTraffic Ev ent Information Servi ce

    Dynamic Traffic Data

    Traffic Data Service

    (dynamic)

    WFS

    Non-Road Information DataEvent 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-changedtraffic condition caused by an event in the map.

    2. Based on the TISP request, RDSS provides to the TISP dynamic road information throughWFS interface getDynamicRoadData and temporary dynamic information that are closelyrelated 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 andservice 6). The extension includes:

  • 8/11/2019 Its Multimodal Servis Eu

    46/56

    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 relatingto their departures. This is limited to those transit services which are of direct relevance toroad users, e.g. connecting rail or ferry services.

    Service Disruption(information about fuel shortage, service area closed, some commercialservice 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 RDSSwith a highlight on the functionalities provided by each In-Time service. It is a reference way ofrepresenting the working principles of the user interaction with the In-Time system.

    The definition is based on the analysis in D2.4.1

  • 8/11/2019 Its Multimodal Servis Eu

    47/56

  • 8/11/2019 Its Multimodal Servis Eu

    48/56

    In-Time

    Pilot Type B

    D3.1.2 UML schemes finalized Specification V1.0

    Page 48 of 56

    RDSSTISP

    End User Service

    WFS:

    getDynamicTrafficData

    WFS:

    getDynamicWeatherData

    device

    End User Device

    Road DataWeather Information Servic e

    Dynamic Traffic Data

    Traffic Data Serv ice

    (dynamic) WFS

    Dynamic Weather Information Data

    Weather Data Serv ice

    (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 relatedto 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 allservice covered areas.

    3. Based on these requests, the RDSS provides continuously the TISP current weatherinformation 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 andservice 6). This extension includes:

    Various weather conditions (ice, heavy rain, snowfall, etc...)

    Location reference (Assignment of various weather condition to road segments )

  • 8/11/2019 Its Multimodal Servis Eu

    49/56

    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 RDSSwith a highlight on the functionalities provided by each In-Time service. It is a reference way ofrepresenting 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

    includeinclude

    use

    use

    precedes

    use

    include

    provide

    precedes

    provide

    provide

    invokes

    include

    includeinclude

    use

    provide

    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 numberor Air Company. The information is provided by the RDSS.

  • 8/11/2019 Its Multimodal Servis Eu

    50/56

    In-Time

    Pilot Type B

    D3.1.2 UML schemes finalized Specification V1.0

    Page 50 of 56

    RDSSTISP

    End User Service

    WFS:getFlightData

    device

    End User Device

    Road DataFlight Information Serv ice

    Static Flight Data

    Dynamic Flight

    Data

    Flight Data Serv ice

    (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 dynamicflight information.

    2. Based on the request parameters from the TISP, the RDSS provides to the TISP static ordynamic 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

  • 8/11/2019 Its Multimodal Servis Eu

    51/56

    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 RDSSwith a highlight on the functionalities provided by each In-Time service. It is a reference way ofrepresenting 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 TimesSpecify Flight

    Numbers

    Get Flight Information

    Get Time Schedule

    Get real-time

    arrival/departures

    Integrate Flight

    Information

    TISP

    Flight Information

    RDSS

    End User Application

    precedes

    include

    include

    include

    use

    include

    precedes

    include

    provide

    invokes

    provide

    invokes

    invokes

    precedes

    Figure 3-33: Use Case Diagram of Service 16

    3.17 In-Time Service 17 Comparative Dynamic Multi Modal JourneyPlanning

    This use case is in fact the only end-user service delivering routing information offeringsimultaneously all travel choices at once. The generation of the multi-modal route can be realizedseveral 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 andpedestrians 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 wholejourney to TISP, or TISP gets separate routes for every stage of the journey from RDSS andgenerates the whole multi-modal journey at its side. Both possibilities are depicted in the Figure3-34 and Figure 3-35 respectively.

  • 8/11/2019 Its Multimodal Servis Eu

    52/56

    In-Time

    Pilot Type B

    D3.1.2 UML schemes finalized Specification V1.0

    Page 52 of 56

    Dynamic Multi-Modal Planning Servic e

    RDSS

    TISP

    End User ServicegetMultiModalRoute

    Road Data

    device

    End User Device

    This diag ram represent

    a TISP who provides a

    multi-modal journey

    information coming

    directly from the RDSS

    Multi-modal Journey

    Planning

    Application getMultiModalRoute

    Cycling Information

    Individual T raffic Data

    Walking Information

    Dynamic Publ ic Transport Data

    Figure 3-34: Service Chain for Dynamic Multi-modal Journey Routing- RDSS route generation

  • 8/11/2019 Its Multimodal Servis Eu

    53/56

  • 8/11/2019 Its Multimodal Servis Eu

    54/56

    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 RDSSwith a highlight on the functionalities provided by each In-Time service. It is a reference way ofrepresenting the working principles of the user interaction with the In-Time system.

    The definition is based on the analysis in D2.4.1

  • 8/11/2019 Its Multimodal Servis Eu

    55/56

    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/pricesrestrictions

    fuel/energy

    consumption

    parking facilities

    Multimodal Route Planner

    TISPRDSS

    dynamic/static route

    data

    Get Route Details

    End User Application

    Map Data

    Other Service Provider

    Specify an address

    (or PT stop)

    precedes

    include

    include

    precedes

    use

    include

    includeinclude include

    include

    include

    include

    include

    include

    provide

    use

    include

    include

    include

    include

    include

    provide

    provide

    provide

    use

    provide

    invokes use

    Figure 3-36: Use Case Diagram of Service 17

  • 8/11/2019 Its Multimodal Servis Eu

    56/56

    In-Time

    Pilot Type B

    4 Conclusion

    In previous sub-chapters every In-Time service was presented in terms of use-case and deploymentdiagrams as well as high-level requirements that are expected from RDSS as response to each TISPrequests. 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 everynet segment and arrival times), or TISP will generate routing itself based on the provided dynamicattributes, that enhance the static features of the road network (speed profiles, work closures, cyclepaths, etc.). These dynamic features may be provided for passenger car and truck routing as well as

    for pedestrian or bicycle routing.