Low Level Function
6.5.10 Provide Traveller Trip Planning Interface

Overview

This Function shall be capable of providing the following facilities:

(1) A HMI through which the Traveller can initiate and manage the trip planning process.
(2) Using the HMI, the ability of the Traveller to define the parameters that are to be used to plan a trip, including origin, destination, places to be visited during the trip before the destination is reached (way points, transport modes to be used, departure time, arrival time, services to be booked, and whatever else is deemed interesting for trip satisfaction.
(3) The ability for the Traveller to use the HMI to request that these parameters are entered into the store of General Trip Preferences Data or to use data in this store to supplement that being provided for a particular trip.
(4) When complete, the ability to send the requirements to the Trip Planning functionality so that the trip plan can be prepared.
(5) The ability to use the HMI to present the prepared trip plan to the Traveller and for the Traveller to be able to refine any of the requirements and re-plan the trip until it fulfils their needs in an iterative way.
(6) The ability to store successive trip plans internally so that they can be re-called by the Traveller if later versions turn out to be unsatisfactory.
(7)  Once a trip plan has been accepted by the Traveller, the Function shall send the details to the Function responsible for producing the travel itinerary or to the Function responsible for making any bookings that are included in the trip plan and/or paying for the trip planning process.
(8) The ability for the Traveller to use the HMI to reject a trip plan and close the trip planning activity at any time and to delete any requirements that have been provided.
(9) The ability for the Traveller to be informed through the HMI about any payments that are needed, either for the trip planning process itself, or for services that the Traveller has specified for inclusion in the trip.
(10) It shall be possible for the Traveller to be asked to pay for the trip planning process either before it starts, or once a successful trip plan has been produced.
(11) The ability of the Traveller to use the HMI to initiate payment for the trip planning service and/or any services that are required as part of the trip, and to be informed of the success or failure of the payment process.
(12) If the payment process fails, the ability to cancel the trip(s) that have been planned and to inform the Traveller of this through the HMI.

Functional Requirements

(a) continuously monitor for the receipt of the basic trip parameters data flow from the pre-trip traveller;
(b) when the data flow in (a) is received, if required send the request applicable General Trip Preferences (GTP) parameters data flow to the GTP management function and wait for the response in the requested applicable GTP parameters data flow;
(c) send the request preferences data flow requesting any changes to the GTP data to the pre-trip traveller and wait for the response in the additional trip parameters data flow;
(d) when the response data flow is received in (c), use its contents and all the other data provided by the traveller to prepare the trip plan requirements, put them in the traveller trip requirement data flow and send it to the Trip Planning function;
(e) as a result of (d) wait for the receipt of the traveller trip description data flow from the Trip Planning function and when it is received, store the trip plan description internally for later use;
(f) output the trip plan description received in (e) to the pre-trip traveller in the initial trip plan data flow;
(g) as a result of (f) wait for a response from the pre-trip traveller in the modified trip parameters data flow;
(h) use the data provided by the data flow in (g) to modify the original trip parameters, put them in the modified trip plan requirements data flow and send it to the Trip Planning function;
(i) as a result of (h) await receipt of the traveller trip description data flow from the Trip Planning function and when it is received store the trip plan description internally for later use;
(j) output the alternative trip plan description received in (i) to the pre-trip traveller in the trip alternatives data flow and wait for a response from the pre-trip traveller in the modified trip parameters data flow;
(k) continue repeating (e) through (i) until no modified parameters are provided by the pre-trip traveller in the modified trip parameters data flow, but giving each revised trip plan description a new identity so that it can be retrieved instead of the other trip plan descriptions;
(l) output the select trip data flow to the pre-trip traveller and await a response through the input of the trip selection data flow;
(m) use the input in (l) to select the required trip plan description from the internal store and check to see if any bookings need to be made and paid for, or the trip plan service needs to be paid for;
(n) if the answer in (m) is YES, send the selected trip plan description to the Make Trip Bookings and Payments function in the full trip description for bookings data flow;
(o) as a result of (n) continuously monitor for receipt of either the request trip planning payment or advanced payment needed data flows from the Make Trip Planning Payment and Bookings function;
(p) then the data flow in (o) is received, send either the request trip planning payment or advanced payment needed by trip plan data flows to the pre-trip traveller and await receipt of either the trip planning payment or booking approval data flows from the pre-trip traveller;
(q) the either of the data flows in (p) is received, send either the trip planning payment or the booking approval data flows to the Make Trip Booking and Payment function;
(r) as a result of (q) continuously monitor for receipt of the full trip description with bookings, or booking mishap data flow from the Make Trip Booking and Payment function;
(s) when the first data flow in (r) is received, inform the pre-trip traveller through the select trip data flow and send the selected trip plan description to the Manage Store of Trip Plan Data function in the plan ready for implementation data flow;
(t) if the answer in (m) is NO, send the selected trip description to the Manage Store of Trip Plan Data function in the plan ready for implementation data flow.

Diagrams

The Diagram(s) is (are) the diagram(s) where you can find the function :
  • DFD 6.5 Prepare Trip Plan
  • Functional Tree of Area 6

    • Parent Higher Level Function

    Input logical dataflows

    Output logical dataflows

    User needs

    Number

    Description

    10.1.4.4
    The system shall be able to provide information that is relevant to travellers with special needs, e.g. obstacles, manually operated doors, manual payment systems, restrictions for guide dogs, etc.
    10.2.1.1
    The system shall provide all the information necessary to prepare a journey.
    10.2.1.9
    The system shall enable the traveller to specify any special needs that he or she may have, e.g. disability, young children, etc.
    10.4.2.1
    The system shall provide information which is legible, understandable and capable of being assimilated very quickly by all travellers.
    10.4.2.2
    The system shall provide information in the native language at the output location, and/or from a user selected choice of other appropriate foreign languages, when applicable.
    6.1.0.1
    The system shall provide emergency, or urgent, information to all road users free of charge.
    6.1.0.2
    The system shall be able to require payment for non-emergency, or non-urgent, information.
    6.1.0.5
    The system shall enable travellers to plan their trip using their own travel criteria (modes of transport, time of departure/arrival, road selection criteria, etc.).
    6.1.0.6
    The system shall enable travellers to plan their trip according to the needs of their disabilities.
    6.1.0.7
    The system shall be able to provide information so that travellers may share a vehicle with others for all or part of a (multi-modal) journey.
    6.1.1.1
    The system shall be able to influence modal shifts according to a specified transport policy.
    6.1.1.2
    The system shall be able to provide trip information on other modes of transport, e.g. for demand-spreading when major events occur, or when weather conditions, strikes, cultural or sports events etc cause problems for one mode.
    6.1.1.3
    The system shall be able to provide current and forecast traffic and travel information for all modes at local, regional, national and international levels.
    6.1.1.4
    The system shall be able to provide extensive multi-modal trip information, e.g. prices, fares, routes, forecast & current traffic situations, traffic control, demand mgt measures, local warnings, special events, weather conditions, hotels etc.
    6.1.2.10
    The system shall be able to provide access information for those travellers with special needs (e.g. physical access, lifts, escalators, parking & toilets, nappy changing rooms, access for (guide) dogs, etc.) at relevant areas, e.g. transit areas.
    6.1.2.11
    The system shall be able to provide information about "Points of Interest", e.g. location, opening times, price of service, nearest transport service points.
    6.1.2.2
    The system shall be able to provide information on the cancellation of departures from an inter-modal interchange (e.g. railway station, an airport , a port or a coach station) due to the weather; strikes or other reasons.
    6.1.2.7
    The system shall provide information using graphical representation or text. Graphical form shall include the use of maps as well as text.
    6.1.3.2
    The system shall be able to require payment for one-off usage of the service.
    6.1.3.3
    The system shall enable the traveller to use cash or electronic means to pay for the one-off usage of the service, where appropriate.
    6.1.3.8
    The system shall be able to provide customised pre-trip information to hand-held and in-vehicle devices.
    6.2.0.1
    The system shall provide emergency, or urgent, information to all users free of charge.
    6.2.0.2
    The system shall be able to require payment for non-emergency, or non-urgent, information.
    6.2.1.1
    The system shall be able to provide alternative routes or mode-switch recommendations when it detects, or is informed, that problems have occurred on a mode.
    6.2.1.3
    The system shall be able to provide information about other transport modes: e.g. location of P+R areas, PT timetable, etc.
    6.2.2.2
    The system shall be able to provide real-time P&R and PT information to vehicle drivers.
    6.2.2.3
    The system shall be able to provide cyclists and pedestrians with information about suitable routes.
    6.2.2.4
    The system shall provide road and traffic safety advice based on current weather and traffic conditions.
    6.2.2.9
    The system shall be able to adapt the information to different classes of users, e.g. travellers, radio broadcasters, service operators.
    6.2.3.1
    The system within the vehicle, or in the centre, shall support various types of presentation to the user.
    6.2.3.2
    The system shall normally provide messages from a finite set of well defined messages.
    6.2.3.3
    The system shall provide information in the native language at the output location, and/or from a user selected choice of other appropriate foreign languages, when applicable.
    6.2.3.4
    The system shall provide information using "open" standard communication protocols.
    6.2.3.5
    The system shall be able to provide customised on-trip information to hand-held and in-vehicle devices.
    6.4.0.1
    The system shall provide travellers with recommended routes to specified destinations.
    6.4.1.1
    The system shall be able to provide guidance to Car Parks (with parking spaces).
    6.4.1.3
    The system shall be able to compute the total predicted journey time over the route selected.
    6.4.1.4
    The system shall be able provide customised navigation information to the destination using a variety of selection criteria.
    6.4.1.5
    The system shall be able to provide guidance to "Points of Interest".
    7.3.0.1
    The system shall provide information that will influence travellers' decisions regarding their destinations, time, mode of travel, route etc.
    7.5.1.1
    The system shall enable a traveller to request and receive journey plans in advance, assess different plans according to certain criteria (e.g. vehicle type, travel time, cost, expected traffic density, planned events, facilities en route, parking), and to save one for future use.
    7.6.2.12
    The system shall be able to provide the pre-trip driver, via an in-vehicle device, with suggested alternative routes.
    7.6.2.2
    The system shall enable the driver of the host vehicle to provide the destination and personal settings for the journey (e.g. desired route, way points, special needs).
    7.6.2.3
    The system shall enable a traveller to request and receive personalised journey plans in advance, assess different plans according to certain criteria (e.g. vehicle type, travel time, cost, expected traffic density, planned events, facilities en route, parking), and to save one for future use.
    7.6.2.8
    The system shall be able to provide the driver, via an in-vehicle device, with a personalised route.