ISO/TR 17185-3:2015
(Main)Intelligent transport systems — Public transport user information — Part 3: Use cases for journey planning systems and their interoperation
Intelligent transport systems — Public transport user information — Part 3: Use cases for journey planning systems and their interoperation
ISO/TR 17185-3:2015 is to define high level general requirements of journey planning systems by standardizing use cases. This part of ISO 17185 defines basic requirements for implementing the journey planning system, from the viewpoint that the public transport users should be provided with convenient tool to make his or her journey more efficient ones. In order to realize the desirable journey planning system, public transport information has to be efficiently processed and provided to public transport users in an appropriate way by using currently available regional standards. This part of ISO 17185 does not standardize specific information interfaces such as data format or a stop point numbering system and so on but currently available regional standards established by regional and national groups are suggested to be applied. ISO 17185 is composed of the following parts: - Part 1: Standards framework for public information systems: (International Standard) - Part 2: Data and Interface standards catalogue and cross reference: (Technical Report) - Part 3: Use cases for journey planning systems and their inter-operation: (Technical Report)
Systèmes intelligents de transport — Partie 3: Cas utiles pour les systèmes de planification de voyage et leur interopération
General Information
Standards Content (Sample)
TECHNICAL ISO/TR
REPORT 17185-3
First edition
2015-05-01
Intelligent transport systems — Public
transport user information —
Part 3:
Use cases for journey planning
systems and their interoperation
Systèmes intelligents de transport —
Partie 3: Cas utiles pour les systèmes de planification de voyage et
leur interopération
Reference number
©
ISO 2015
© ISO 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – All rights reserved
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 4
5 General requirement. 5
5.1 Importance of PT user information provision . 5
5.2 Objectives of ISO 17185 . 6
5.3 Roles and responsibilities of basic actors in journey planning system . 6
5.3.1 PT service operator . 6
5.3.2 PT JP service provider . 7
5.3.3 Data provider . 7
5.3.4 PT user . 7
5.4 Use cases description of journey planning system . 7
5.4.1 Methodology used for the use case definition . 8
5.4.2 Use case categorization . 9
5.4.3 Operational scenario .11
5.4.4 User use cases .12
5.4.5 Administrator use cases .36
5.5 Currently available regional standards .42
Annex A (informative) Currently available regional journey planning systems .45
Bibliography .49
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of any
patent rights identified during the development of the document will be in the Introduction and/or on
the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical Barriers
to Trade (TBT), see the following URL: Foreword — Supplementary information.
The committee responsible for this document is ISO/TC 204, Intelligence Transport Systems.
ISO 17185 consists of the following parts, under the general title Public transport user information:
— Part 1: Standards framework for public information systems
— Part 3: Use cases for journey planning systems and their inter-operation [Technical Report]
The following parts are under preparation:
— Part 2: Data and interface standards catalogue and cross reference [Technical Report]
iv © ISO 2015 – All rights reserved
Introduction
ISO/TC 204, Intelligent Transport Systems, has been discussing enhancement of surface public transport
information provision to surface public transport users including international travellers around the
world by using ITS technology.
The responsibility of ISO/TC 204 is make surface public transport more convenient by realizing stress-
free surface public transport user information provision, and hence, the technical committee has been
working to develop one set of international standard and several technical reports which are defining
basic framework and practical uses cases that will fit above current national and regional standards
as a reference. The accepted national and regional standards (at this point in time, such as TCIP and
TRANSMODEL) will be allowed to define the specific information interfaces such as data format,
stop point numbering system, etc. that are necessary to implementation of surface public transport
information systems.
The set of International Standard and Technical Reports will be beneficial for all ISO/CEN member
countries as well as non ISO/CEN member countries. The International Standard/Technical Reports will
be a valuable reference to detail basic framework as well as highlight and encourage use of currently
available national and regional standards such as TRANSMODEL, TCIP, and possibly others. The intention
is that, by deploying these national and regional standards by other countries or regions, duplication of
cost and time is avoidable. For those countries that do not have surface public transport information
standards, this approach allows more rapid development and deployment of public transport systems
that enhance usability and convenience.
ISO 17185 is specifically set at a higher level, or reference and not aiming harmonize currently available
national and regional standards to allow use of these robust standards which are set at various levels (for
example implementation specifications versus application level standards) but which also experience
widespread acceptance in their regional standards. This International Standard intends to establish
a basic solid foundation for surface public transport user information provision framework and is
specifically limited to this scope to avoid conflict with those currently available regional standards.
ISO 17185 is intended to be fully consistent with those currently available national and regional standards
which may be related to international public transport. In fact, in the case of international surface public
transport, public transport operators already have transport-related information systems. However,
public transport users, including international travellers, are often not provided with static and real time
information including bus/train/tram locations in an appropriate and timely manner. ISO 17185, and its
scope and approach, will solve this issue by setting basic framework for public transport information
provision while embracing existing national and regional standards.
TECHNICAL REPORT ISO/TR 17185-3:2015(E)
Intelligent transport systems — Public transport user
information —
Part 3:
Use cases for journey planning systems and their
interoperation
1 Scope
The purpose of this part of ISO 17185 is to define high level general requirements of journey planning
systems by standardizing use cases.
This part of ISO 17185 defines basic requirements for implementing the journey planning system, from
the viewpoint that the public transport users should be provided with convenient tool to make his or her
journey more efficient ones. In order to realize the desirable journey planning system, public transport
information has to be efficiently processed and provided to public transport users in an appropriate
way by using currently available regional standards.
This part of ISO 17185 does not standardize specific information interfaces such as data format or a stop
point numbering system and so on but currently available regional standards established by regional
and national groups are suggested to be applied.
ISO 17185 is composed of the following parts:
— Part 1: Standards framework for public information systems: (International Standard)
— Part 2: Data and Interface standards catalogue and cross reference: (Technical Report)
— Part 3: Use cases for journey planning systems and their inter-operation: (Technical Report)
2 Normative references
There are no normative references.
3 Terms and definitions
For the purpose of this document, following terms and definitions apply.
3.1
administrator
person charged with the installation, configuration, and management of a computer system, network,
storage subsystem, database, or application
[SOURCE: ISO/IEC 24775:2011, 2.1.4, modified]
3.2
data
reinterpretable representation of information in a formalized manner suitable for communication,
interpretation, or processing
Note 1 to entry: Data can be processed by humans or by automatic means. [ISO/IEC 2382-1:1998, (01.01.02)]
[SOURCE: ISO/IEC 15944, modified]
3.3
database
collection of electronically stored descriptive records or content units (including facts, full texts,
pictures, and sound) with a common user interface and software for the retrieval and manipulation of
the data
Note 1 to entry: The units or records are usually collected with a particular intent and are related to a defined
topic. A database can be issued on CD-ROM, diskette, or other direct-access method, or as a computer file accessed
via dial-up methods or via the Internet.
Note 2 to entry: Licensed databases are counted separately even if access to several licensed database products is
effected through the same interface.
Note 3 to entry: A common interface providing access to a packet of serials or digital documents, usually offered
by a publisher or vendor, is also to be counted as database. Additionally, the single serials or digital documents
should be counted as serials or digital documents. [ISO 2789:2006, 3.2.10]
[SOURCE: ISO 9707, modified]
3.4
data model
graphical and/or lexical representation of data, specifying their properties, structure, and inter-
relationships
[SOURCE: ISO/IEC 11179, modified]
3.5
entity
concrete or abstract thing that exists, did exist, or might exist, including associations among these things
EXAMPLE: A person, object, event, idea, process, etc.
Note 1 to entry: An entity exists whether data about it are available or not. [ISO/IEC 2382-17:1999, (17.02.05)]
[SOURCE: ISO/IEC 15944, modified]
3.6
fare collection
all activities related to the collection of money from passengers
3.7
framework
structure expressed in diagrams, text, and formal rules which relates the components of a conceptual
entity to each other
[SOURCE: ISO 19439:2006, 3.3, modified]
3.8
function
intended effect of a system, subsystem, product, or part
[SOURCE: EN 1325-1:1997]
Note 1 to entry: Functions should have a single definite purpose. Function names should have a declarative
structure (e.g. “Validate telecommands”), and say “what” is to be done rather than “how”. Good naming allows
design components with strong cohesion to be easily derived.
[SOURCE: ISO 16091, modified]
2 © ISO 2015 – All rights reserved
3.9
functional area
combination of groups and/or elements in a unit that can be used independently
[SOURCE: ISO 16952, modified]
3.10
IC
integrated circuit
a small piece of semiconductive material that contains interconnected electronic elements
[SOURCE: ISO/IEC 2382-1, modified]
3.11
logical data model
data design, that takes into account the type of database to be used, but does not consider means of
utilisation of space or access
3.12
management information
information utilized by management or produced to serve a management function
[SOURCE: ISO 6707-2, modified]
Note 1 to entry: In this part of ISO 17185, this term means all activities allowing the company management to
collect the information necessary to meet problem-solving needs. Data of operational systems are filtered and
aggregated for this purpose, and made available to the user interactively, or in form of pre-defined reports and
summaries. Such functions are in principle related to all functional areas of a company, with particular reference
to the management of statistical results.
3.13
operations monitoring and control
all activities related to the transportation process, i.e. real-time functions related to the driving and
transportation of passengers according to given instructions, including the monitoring of the driving
process and its control in case of deviations, as well as all activities that support the driving process
(traffic light priority, track switching, bay selection, advance/delay advice, etc.)
Note 1 to entry: Such functions are often assisted by computer-aided tools, known as Automated Vehicle
Monitoring (AVM).
3.14
passenger information
activities related to informing the users either on the planned or on the actual transportation services
3.15
personnel disposition
activities related to the mid-term and short-term management of drivers
3.16
scheduling
method of controlling the timing of the execution of a scheduled activity within or represented by a
managed object
[SOURCE: ISO/IEC 10164, modified]
Note 1 to entry: In this part of ISO 17185, this term means all activities related to the tactical planning of
transportation, splitting into vehicle scheduling, driver scheduling, rostering.
3.17
use case
sequence of actions that an actor (usually a person, but perhaps an external entity, such as another
system) performs within a system to achieve a particular goal
[SOURCE: ISO/TR 25102, modified]
3.18
user
entity that uses ITS services provided by a service provider
[SOURCE: ISO 24101-1:2008, 3.13, modified]
4 Symbols and abbreviated terms
AVL automatic vehicle location
BISON Beheer Informatie Standaarden OV Nederland, Netherlands public transport informa-
tion standards management platform
CEN European Committee for Standardization
DE Germany
EU European Union
GPS global navigation system
IEC international electro-technical commission
IFOPT identification of fixed objects in public transport, CEN published standard (EN 28701)
ISO international organization for standardization
ITS intelligent transport systems
JP Journey planning
NaPTAN National Public Transport Access Nodes, GB national system for uniquely identifying
all the points of access to public transport in GB
NEPTUNE French standard (PR NF 99-506) for format describing public transport routes
NeTEx Network Exchange, EN TC278 WG3 standard currently in development and the goal is
to provide efficient European wide standard for exchanging public transport sched-
ules and related data.
POI point of interest
PT public transport
SIRI service interface for real time information, CEN technical specification (TS 15531)
TCIP transit communications interface profiles, US standard developed by APTA and is for
introducing advanced ITS technologies into public transport to improve safety, secu-
rity, and efficiency
4 © ISO 2015 – All rights reserved
Transmodel CEN standard (EN 12896) for reference data model for public transport informa-
tion and it provide an abstract model of common public transport concepts and data
structures that can be used to build many different kind of public transport informa-
tion system, including for timetabling, fares, operational management, real time data,
journey planning, etc.
TransXChange GB nationwide standard for exchanging bus schedules and related data
5 General requirement
This part of ISO 17185 describes use cases for journey planning systems and their inter-operation of PT
user information provisions for PT users, the customers. For the detailed data and interface standards
catalogues and cross reference, which fits to those who do not have their own regional and national
standards, refer to ISO/TR 17185-2.
5.1 Importance of PT user information provision
PT service operator shall play an important role in surface transport as the society fully depend upon
privately-owned cars has its own limitation such as high environmental impact, increasing number of
accidents related to aged drivers, and shrinking economy due to scattered population.
The issue of the current PT to be solved varies country to country or city to city, but the following
common vision can be observed. From PT service operator view point, benefit/cost factor can be kept
high by deploying ITS technologies such as simple and efficient fare transaction device, priority traffic
control signal system, etc. From PT user, the customer, view point, PT use shall be more attractive than
driving his/her own cars by improving PT transport speed and reducing PT fare, and by providing
attractive PT user information to PT users, the customers.
When providing PT user information, it is important to understand that there are various types of
customers and their needs vary between customer types. In local resident, there are two types, one
who does not know how to use PT, the other who knows basic information and understands that PT is
reliable transport means in time and safety. Usually visitor is not familiar with local PT and convenient,
accessible and easy to use PT service and information. Therefore, PT user information provision
framework shall be designed to accommodate those various needs.
Various PT information provision projects are under practical use, and the project status reports
are commonly shared internationally to improve PT user information provision system continuously
throughout the world.
There are several key issues concerning PT when creating “PT user” friendly society, namely;
— attractive PT user information provision to potential PT user, the customers;
— attractive PT contactless card system;
— efficient and attractive PT service in timetabling and service route;
— good relationship between regional transit regulator and PT service operator;
— better relationship between PT driver and PT service operator by deploying ITS technologies.
Therefore, defining basic PT user information provision framework, which is commonly acceptable
internationally, is indispensable for both of advanced and emerging countries, where PT user information
provision system improvements are needed. This is the purpose of ISO 17185-1.
The PT user information provision service architecture and required standards needed varies country to
country and therefore, this international standard is not defining new rules but provide basic framework
guide lines which shall be referred when such PT information provision system is implemented.
This part of ISO 17185 describes detailed use cases of journey planning systems and their inter-operation.
For the detailed data and interface standards catalogues and cross reference, which fits to those who do
not have their own regional and national standards, refer to ISO/TR 17185-2.
5.2 Objectives of ISO 17185
The objectives of ISO 17185 are defined as follows.
Part 1: Define the high level stakeholder roles and responsibilities and their PT user information
exchanges.
Part 2: Define data interface message comparison.
Part 3: Define use cases for journey planning systems and their inter-operation where in the worldwide
standards apply and it may include exchange of information using nomadic devices
Overall, in ISO 17185, it describes a framework to facilitate inter-operability of public transport-related
information using different national/regional standards, off the shelf of use of standards, help to guide
evolution of standards worldwide to a common framework, identify gaps in existing standards and
translate between existing standards to facilitate PT users including worldwide travellers.
This is accomplished through, definition of the high level stakeholder roles and responsibilities and PT
user information exchange, data and interface message comparisons, use cases wherein the worldwide
standards apply.
5.3 Roles and responsibilities of basic actors in journey planning system
As described in ISO 17185-1, the basic actors of PT journey planning system are shown in Figure 1 below.
In the basic PT JP (journey planning) system, four major basic actors are defined as shown in Figure 1.
This is shown as basic system framework as an example and at actual system implementation phase,
some of those actors shall be modified to fit to each countries service requirements and circumstances.
Data request Data request
and response and response
PT JP SERVICE
PROVIDER
PT SERVICE DATA
(Administrator)
OPERATOR(S) PROVIDER(S)
Data request
Direct
and response
transaction
such as
payement
for tickets
which is out
PT USER
of scope of
(User)
this TR
Figure 1 — Basic actors in PT JP system
5.3.1 PT service operator
PT service operator is an entity who operates PT service and in the PT JP system, its function is to
provide accurate and up-to-date PT information, such as bus stop/station, vehicle location, scheduled
service, ticketing, fare, reservation status, payment status to PT JP service provider. The PT JP service
provider sends PT users seat reservation request to PT service operator and receives request results.
6 © ISO 2015 – All rights reserved
The PT USER access such information through PT JP service provider. This entity is composed of the
following sub actors:
a) transport service provider;
b) transport service manager;
c) transport operation manager.
For more details, refer to ISO 17185-1.
5.3.2 PT JP service provider
PT JP service provider is an entity who gathers single or multiple modes (such as bus, train, airplane,
tram, metro) and/or single or multiple PT service operators data and provide value added PT JP service
to PT user through internet for PC and mobile device and digital TV network. The PT JP service provider
for multimodal is often called multi-modal JP service provider. When data format is deferent from PT
service operator to PT service operator, data conversion function shall be added in the data line from PT
service operator(s).
Responsible for the provision of PT JP information services to PT users or others. Those services may
be including journey route search (such as bus stop/station, route, travel time, fares, mobility restricted
information), reservation status, payment status, schedules service, ticketing, vehicle location, etc. The
major communication link to PT user is currently done through internet with WEB service.
Administrator of PT JP service provider shall perform the system maintenance for updating the system
database and improving the services quality.
5.3.3 Data provider
Data provider is an entity who gathers multiple type of information, such as interchange information,
such as length and time of foot path between stop points, stairs, escalators, lifts, information for
challenged people (or people with big suite case, baby buggy, etc.), disruption information to escalators,
lifts, blockages of corridors, access to stop points, etc., graphs for calculating pedestrian (and optional
park and ride and cycle and ride) routes from and to the PT station, disruption information for the foot
path from and to the stations (plus optional park and ride, cycle and ride, cycle, etc.), addresses, POIs,
regional names, zoom able background maps for display. This actor may be private sector or municipal,
state, federal government body.
5.3.4 PT user
PT user is a human who use PT service. When a PT user provides geographical location data such as
GPS location data to PT JP service provider, the PT user can receive real time route navigation service
through mobile device such as smart phone. The PT user is responsible to plan/define journey plan, find
best transport route, re-plan journey when needed. In the use cases description defined in 5.4.4, it is
described as “user”.
5.4 Use cases description of journey planning system
The use case descriptions of the journey planning systems and their inter-operations shall be defined as
shown below. Use cases defined in ISO 17185 are described as informative purpose only and in the real
implementation of the journey planning systems, some of these use cases shall be modified to fit each PT
service requirements and circumstances.
These use cases described in this part of ISO 17185 do not preclude any “presentation layer” format such
as web, mobile web, interactive voice response (phone), or kiosk. A presentation layer represents user
interface capabilities as shown in Figure 2 below.
Service layer Presentation layer
Web
Use cases
Mobile web
Interactive voice (phone) response
Kiosk
Figure 2 — Service layer and presentation layer
5.4.1 Methodology used for the use case definition
Each use case definition is described in same type of table as shown below. This table shows what each
item means. Although these use cases are described based upon a PC web type presentation layer service
interface, when implement the journey planning systems, all other modes of presentation methods can
be adopted, such as mobile web, interactive voice (telephone) response and kiosk.
Use Case Name of each use case
Description Brief description of system inter-action when this use case is performed
Actor Who initiate to make the system start this use case into action
Assumptions Condition right before this use case has been started
Interactions Step by step description of system inter-actions when this use case is performed
Results Description of the result right after this use case has been performed
Issues The statement of issues to make this use case perform better;
System improvements
Service improvements
Performance improvements
UML diagram Use case diagram.
Following is shown for journey planning system general use case.
8 © ISO 2015 – All rights reserved
Use Case Name of each use case
5.4.2 Use case categorization
In this part of ISO 17185, following use cases are defined. Each use case can be categorized as follows:
a) User use cases
1) Read Instructions : information
2) Select Type of Public Transport : selection
3) Select Departure stop/station : selection
4) Select Destination stop/station : selection
This key user interface
5) Select Via stop/station : selection
of journey planning
system will include
6) Select Date : selection
most of these selection
menus ( 2) through
7) Select Time : selection
11) ) on same window
so that users can
8) Select Preference : selection
easily and
conveniently do their
9) Select Combination Type of Walking and : selection
preference selection
Driving
for journey planning
search in a convenient
10) Select Walking Speed : selection
11) Select Preference of Wheelchair Use : selection
12) Search for Journey : search
13) Search for Next Departure Service : search
14) Search for Previous Departure Service : search
15) View Journey on Map : information
16) View Real Time Route Navigation : information
17) Search for Return Journey : search
18) Return to New Search : search
19) View Scheduled Service Information : information
20) View Real Time Service Station/Stop : information
Information
21) View Real Time Route/Line Information : information
22) View Detour Information : information
23) View Incident Information : information
24) View Delay Information : information
25) Report User Real Time Information : report
26) View User Reported Real Time : information
Information
27) View Vehicle Location on Map : information
28) View Seat Availability : information
29) Book Seat Reservation : reservation
30) Reconfirm Seat Reservation : information
31) Confirm Payment Status : information
32) Print Ticket : print
Subscription (push type status information) information
b) Administrator use cases
1) System Log-in : operation
2) Add Stop/Station : maintenance
3) Delete Stop/Station : maintenance
4) Commission Stop/Station : maintenance
5) Close Stop/Station : maintenance
6) Add Route/Line : maintenance
7) Delete Route/Line : maintenance
8) Open Route/Line : maintenance
9) Close Route/Line : maintenance
10) System Log-out : operation
10 © ISO 2015 – All rights reserved
5.4.3 Operational scenario
Following operational scenario can be expected when journey planning system is in use. The use case
category types defined in 5.4.2 are used for simple expression of each scenario.
a) User operational scenario
1) Before departing for journey
2) During journey
b) Administrator operational scenario
5.4.4 User use cases
Users of the journey planning system use cases are defined as follows. Some users will require more
than one use case provided at the same time to meet their needs. For example, journey planning request
includes multiple combinations of the use cases from 5.4.4.2 through 5.4.4.11.
5.4.4.1 Read Instructions
Use Case Read Instructions
Description The user clicks on “Instruction” button, the system read the instructions from a text file
and displays instructions about how to use the system. After the user has finished read-
ing the instruction, the user can resume journey planning.
Actor User
Assumptions Application has loaded without errors.
12 © ISO 2015 – All rights reserved
Use Case Read Instructions
Interactions a) System opens specified file containing instructions.
b) System reads instructions from the file and attaches them to an instruction display
box.
c) System displays the dialogue box containing instructions.
d) User reads instructions.
Results System has responded by displaying application window with instructions.
User can use the system easily even in the first time.
User can be skilled in using the system.
Issues Multi language function shall be available when the international traveller uses are
expected.
UML diagram
5.4.4.2 Select Type of Public Transport
Use Case Select Type of Public Transport
Description The user defines the type of public transport to be used.
Actor User
Assumptions System has loaded without errors.
User may know exact type of transport.
Interactions a) User requests for selection of type of public transport by clicking on the type of
transport button.
b) System displays types of transport in list.
c) User selects one or more type of type of transport from list.
d) System confirms returned type of transport and displays it in the type of transport
display field.
Results Type(s) of transport is confirmed and displayed in type of transport display field.
User can define type of transport (such as subway, tram, train, bus, coach, demand
a
responsive transport ) for the journey.
Issues
a
Demand Responsive Transport or Demand-Responsive Transit (DRT) or Demand Responsive Service or Dial-a-ride or
Flexible Transport Services is “an advanced, user-oriented form of public transport characterized by flexible routing and
scheduling of small/medium vehicles operating in shared-ride mode between pick-up and drop-off locations according to
passenger needs”. In many areas, DRT is instead known as DART, or Dial-a-Ride Transit.
Use Case Select Type of Public Transport
UML diagram
a
Demand Responsive Transport or Demand-Responsive Transit (DRT) or Demand Responsive Service or Dial-a-ride or
Flexible Transport Services is “an advanced, user-oriented form of public transport characterized by flexible routing and
scheduling of small/medium vehicles operating in shared-ride mode between pick-up and drop-off locations according to
passenger needs”. In many areas, DRT is instead known as DART, or Dial-a-Ride Transit.
5.4.4.3 Select Departure Stop/Station
Use Case Select Departure stop/station
Description The user defines the departure stop/station.
Actor User
Assumptions System has loaded without errors.
User may know exact stop/station name.
Interactions a) User requests for selection of departure stop/station by clicking on the departure
stop/station button.
b) User selects type of departure point by clicking on “stop/station”, “address”, “land-
mark” button.
c) User types criteria in the text field.
d) System displays candidate list.
e) User selects departure stop/station by clicking on the departure stop/station list.
f) System confirms returned stop/station as departure stop/station and displays it in
the departure stop/station display field.
Results Departure stop/station is confirmed and displayed in departure stop/station text field.
User can define departure stop/station for the journey.
Issues User needs to find the nearest point of access to PT by some means.
System needs to use gazetteers and other mechanism to make location-based search to
find the departure stop/station.
System shall remember previously selected stop/station and list it on top of the list for
faster search at next search by user.
14 © ISO 2015 – All rights reserved
Use Case Select Departure stop/station
UML diagram
5.4.4.4 Select Destination Stop/Station
Use Case Select Destination stop/station
Description The user defines the destination stop/station.
Actor User
Assumptions System has loaded without errors.
User may know exact stop/station name.
Interactions a) User requests for selection of destination stop/station by clicking on the destination
stop/station button.
b) User selects type of departure point by clicking on “stop/station”, “address”, “land-
mark” button.
c) User types criteria in the text field.
d) System displays candidate list.
e) User selects destination stop/station by clicking on the destination stop/station list.
f) System confirms returned stop/station as destination stop/station and displays it in
the destination stop/station display field.
Results Destination stop/station is confirmed and displayed in destination stop/station display
field.
User can define destination stop/station for the journey.
Issues User needs to find the nearest point of access to PT by some means.
System needs to use gazetteers and other mechanism to make location-based search to
find the destination stop/station.
System shall remember previously selected stop/station and list it on top of the list for
faster search at next search by user.
Use Case Select Destination stop/station
UML diagram
5.4.4.5 Select Via Stop/Station
Use Case Select Via stop/station
Description The user defines the via stop/station.
Actor User
Assumptions System has loaded without errors.
User may know exact stop/station name.
Interactions a) User requests for selection of via stop/station by clicking on the via stop/station
button.
b) User selects type of departure point by clicking on “stop/station”, “address”, “land-
mark” button.
c) User types criteria in the text field.
d) System displays candidate list.
e) User selects via stop/station by clicking on the via stop/station list.
f) System confirms returned stop/station as via stop/station and displays it in the via
stop/station display field.
Results Via stop/station is confirmed and displayed in via stop/station text field.
User can define via stop/station for the journey.
Issues User needs to find the nearest point of access to PT by some means.
System needs to use gazetteers and other mechanism to make location-based search to
find the destination stop/station.
In planning a multi-leg journey plan through a network, system needs to take into
account the transfer time needed to transfer between services at an interchange point.
Transfer time varies under different constraints for mobility restricted users. See use
cases 5.4.4.10 and 5.4.4.11.
System shall remember previously selected stop/station and list it on top of the list for
faster search at next search by user.
16 © ISO 2015 – All rights reserved
Use Case Select Via stop/station
UML diagram
5.4.4.6 Select Date
Use Case Select Date
Description The user selects Date of travel.
Actor User
Assumptions System has loaded without errors.
User knows travel date.
Interactions a) User selects date of travel from date list. It shall include “depart now” button and
when user clicks it, system shall move to 5) below. “Calendar” button shall be provided
in next to text filed so that user can select date by clicking on the date desired and text
filed is automatically filled with desired date text.
b) User selects month of travel from month list.
c) User selects year of travel from year list.
d) System combines select date, month and year into format dd/mm/yy.
e) System confirms combined date, returns and displays it in date text field.
Results Date of travel is confirmed and displayed in date text field.
User can define date of the journey.
Issues
UML diagram
5.4.4.7 Select Time
Use Case Select Time
Description The user selects departure or arrival time of travel.
Actor User
Assumptions System has loaded without errors.
User knows departure time or arrival time of travel.
Interactions a) User selects desired departure or arrival of travel from list. It shall include “depart
now” button and when user clicks it, system shall move to e) below.
b) User selects type of time either depart or arrival from list.
c) User selects time of travel from list. It shall include AM and PM selection buttons.
d) System displays in a format of hh/mm/AM or hh/mm/PM.
e) System confirms combined time, returns and displays it in time text field.
Results Desired departure or arrival time of travel is confirmed and displayed in the text field.
User can define desired departure or arrival time of the journey.
Issues This is very useful function when user is on middle of journey and wishes to make some
changes in his/her journey plan.
UML diagram
5.4.4.8 Select Preference
Use Case Select Preference
Description The user selects preference of travel.
Actor User
Assumptions System has loaded without errors.
User knows preference of travel.
Interactions a) User selects desired preference of travel from the list. It shall include “Earliest
arrival”, “Lowest fare”, “Fewest changes”, “Least walking” menu.
b) User selects type of preference from list.
c) When user selects “Least walking”. It shall show next list for user selection of walk-
ing distance such as 5 min., 10 min., 15 min., 20 min., 25 min., 30 min., etc.
d) System displays user preferences.
e) System confirms and displays in text field.
Results User can define preference of the journey.
Issues
18 © ISO 2015 – All rights reserved
Use Case Select Preference
UML diagram
5.4.4.9 Select Combination Type of Walking and Driving
Use Case Select Combination Type of Walking and Driving
Description The user selects combination type of “walking and driving” of travel.
Actor User
Assumptions System has loaded without errors.
User knows combination type of “walking and driving” of travel.
Interactions a) User selects desired combination type of “walking and driving” of travel from the
list. It shall include “walking only”, “cycle and ride”, “park and ride” menu.
b) User selects combination type from list.
c) System displays user selection result.
d) System confirms and displays in text field.
Results User c
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...