To provide accurate and efficient demand responsive services to all elderly users
Primary actor
Young elderly (ages 55-65)
Elderly (ages 65-75)
Old elderly (ages 75+)
Secondary actor(s)
Service Centre
Connected UCs
Plan a Trip
Pedestrian routing UC
Booking UC
Priority Level
Essential
Scenario(s)
The user enters the place of origin and destination of the new trip, the desired starting date and time and the option for DRT (Demand-Responsive Transportation) services. In case there are valid results returned from the request he/she can optionally contact the respective service and follow the instructions (time and place of pick up) provided by the service.
System output
The system checks if the origin and destination of the trip are inside an area where there are Demand Responsive Transport services registered that cover both O-D, either for door to door service or pick up points. In the latter case a proximity of both O-D to available pick up points should run and check if proximity radius is within user’s preference.
If a DRT service, that meets the user’s preferences, exists, the system makes the respective request providing all necessary details – e.g. in case a DRT door to door service supplies the O-D details and user details to the DRT service. When there is an answer by the DRT service (accept or decline), this is returned with the request id to the oasis server. The result is presented at the GUI level as an alert to the user. If the user accepts the service, the system provides all the necessary details, such as DRT service contact details -phone, sms, email-, instructions for time and place of pick up, responds to the DRT service, and removes the temporary request from its DB. Since the DRT request and the answer from the DRT service might be asynchronous, there might be a time gap in the scenario execution between the request and the presentation of the result at the GUI level.
In case of DRT pick up point service, additionally and after the user acceptance, the system asks the respective oasis subsystem for pedestrian routing from the origin to the starting pick up point and from the ending pick up point to the destination, which is then presented to the user.
A matter that arises here is that of the DRT business rules. Usually a phone call to such a system is bounding whereas in the case of an email or sms, an additional phase of acceptance and validation of the service is needed (the problem of the time gap presented earlier).
For an actual reservation, the system should contact the respective oasis reservation subsystem, if such is available.
Step 2 – The oasis server accepts the request and proxies it to our system with a unique request id, that is stored temporarily in the system’s database
Step 3 – The user provides origin, destination, date and time information
Step 4 – The system checks if the origin and destination are inside an area where there are DRT services registered. If so the system makes the request supplying the origin and destination details and user details to the DRT service. When there is an answer by the DRT service (accept or decline), this is returned with the request id to the oasis server. The result is presented at the GUI level as an alert to the user
Step 5 – The user accepts the service.
Step 6 – The system provides information for the DRT service such pickup & delivery details and contact information to the user, responds to the DRT service and the temporary request is removed from the database.
Step 7 – In case of DRT pick up point service, additionally and after the user acceptance, the system asks the respective oasis subsystem for pedestrian routing from the origin to the starting pick up point and from the ending pick up point to the destination, which is then presented to the user.
Step 8 – In case a reservation system exists by the DRT service, the system asks the respective oasis subsystem for booking service (if booking services are provided by oasis.
Step 9 – In case there is no DRT service provided, the user can restart the “Plan a trip” asking for a different type of solution, such as PT trip or Rent a special car service
Personalisation/ adaptation level
Yes:
static parameters: adapted UI to potential disabilities
dynamic parameters: preferred time and place of pick up
Quality of service indicators
Calculate optimal route in order to satisfy user demands. Provide accurate information to the elderly user.
Potential input needed from other UCs (what input and which UCs?)
To provide accurate and efficient demand responsive services to all elderly users
Primary actor
Young elderly (ages 55-65)
Elderly (ages 65-75)
Old elderly (ages 75+)
Secondary actor(s)
Service Centre
Connected UCs
Plan a Trip
Pedestrian routing UC
Booking UC
Priority Level
Essential
Scenario(s)
The user enters the place of origin and destination of the new trip, the desired starting date and time and the option for special car rental. In case there are valid results returned from the request he/she can optionally book a car.
System output
The system checks if the origin of the trip is inside an area where there are Special Car Rental services registered, either for door to door service or pick up points. In the latter case a proximity of the origin to available pick up points should run and check if proximity radius is within user’s preference.
If a Special Car Rental service, that meets the user’s preferences, exists, the system performs the request and it returns the result with the request id to the oasis server. The same procedure as per DRT is followed. If and when the car rental system responds positively about car availability, the final car rental offer is presented to the user at the GUI level as an alert to the user. If the user selects this option, the system provides all the necessary details and removes the temporary request from its DB. Since the request and the answer from the service might be asynchronous, there might be a time gap in the scenario execution between the request and the presentation of the result at the GUI level.
In case of car rental pick up point service, additionally and after the user acceptance, the system asks the respective oasis subsystem for pedestrian routing from the origin to the pick up point, which is then presented to the user.
For an actual reservation, the system contacts the respective oasis reservation subsystem. In this case a reservation system is absolutely necessary to complete the procedure.
Relevant OASIS WP
WP3
Services involved
Transport information
Devices & restrictions
11a. User Interaction devices & restrictions
PC, mobile phone, PDA
11b. Sensor devices & restrictions
Critical success parameters
Services
Success parameters
Transport information
Provide accurate and efficient information to the elderly user.
Environmental restrictions
Interaction level
Step 1 – The user initiates a request for special car rental service for a certain trip
Step 2 – The oasis server accepts the request and proxies it to our system with a unique request id, that is stored temporarily in the system’s database
Step 3 – The user provides origin, destination, date and time information
Step 4 – The system checks if the origin is inside an area where there are special car rental services registered that meet user preferences. If so the system makes the request supplying the origin and user details to the service. When there is an answer by the service (accept or decline), this is returned with the request id to the oasis server. The result is presented at the GUI level as an alert to the user
Step 5 – The user accepts the service.
Step 6 – The system provides information for the service such pickup & delivery details and contact information to the user, responds to the service and the temporary request is removed from the database.
Step 7 – In case of pick up point service, additionally and after the user acceptance, the system asks the respective oasis subsystem for pedestrian routing from the origin to the pick up point, which is then presented to the user.
Step 8 – In case a reservation system exists by the car rental service, the system asks the respective oasis subsystem for booking service (if booking services are provided by oasis).
Step 9 – The user can restart the “Plan a trip” asking for a different type of solution, such as PT trip or Demand Responsive Transport service
Personalisation/ adaptation level
Yes:
static parameters: adapted UI to potential disabilities
dynamic parameters: preferred time and place of pick up
Quality of service indicators
Calculate optimal route in order to satisfy user demands. Provide accurate information to the elderly user.
Potential input needed from other UCs (what input and which UCs?)
Important accessibility attributes (per UG)
Take into account the type of disability of the elderly user, if there is one.
Background info/ reason on selection and on assigning the priority level
References
Comments
Figure 84: SP3-22 On demand special rental services
