Project Logo 

Science Shop for Innovative Mobility Solutions for  Mobility Challenged Europeans  InMoSion 
SPECIFIC SUPPORT ACTION 

044645 

Deployment Pr ocess Design 
Deliverable No.  Workpackage No.  Authors  Status  (F:  final;  D:  draft;  RD:  revised  D  draft):  File Name:  Project start date and duration  D.3.3 Deployment Process Design.doc  01 J anuary 2007, 30 Months WP3  D3.3  Workpackage Title  Deployment  Process  Design  and  Documentation 

InMoSion: Deployment Process Design 

Table of contents 

TABLE OF CONTENTS......................................................................................................................2  EXECUTIVE SUMMARY...................................................................................................................4  1  INTRODUCTION......................................................................................................................6  1.1  1.2  2  THE INMOSION PROJECT  .....................................................................................................6  PURPOSE AND LAYOUT OF THIS HANDBOOK  ..............................................................................6 

INITIAL EVALUATION ..............................................................................................................9  2.1  2.2  AREA PROFILE ....................................................................................................................9  DEFINITION OF STAKEHOLDERS.............................................................................................10 

2.2.1  Users.......................................................................................................................10  2.2.2  Operators................................................................................................................11  2.2.3  Government ............................................................................................................11  2.2.4  Drivers/Employees...................................................................................................11  2.2.5  Local market & Touristic businesses.........................................................................12  2.2.6  Competition: other Transportation Service Providers................................................12  2.3  2.4  2.5  2.6  3  4  EXISTING TRANSPORTATION SERVICES IN THE AREA ....................................................................12  EXISTING PUBLIC ORGANIZATIONS AND TRANSPORT ORGANIZATIONS ..............................................13  LEGAL STRUCTURE  ............................................................................................................14  SUMMARY OF THE INITIAL EVALUATION ..................................................................................14 

DELINEATION OF THE PROPOSED TRANSPORT SCHEME .......................................................16  USER SURVEY DESIGN ..........................................................................................................21  4.1  DESIGN OF THE QUESTIONNAIRE ...........................................................................................21 

4.1.1  Part A‐ User Characteristics .....................................................................................22  4.1.2  Part B‐ Trip Characteristics: .....................................................................................23  4.1.3  Part C‐ Transit System Characteristics:.....................................................................23  4.1.4  Part D‐ Paratransit System Characteristics and Preferences:.....................................23  4.1.5  Part E‐ Technological Aspects ..................................................................................24  4.1.6  Part F‐ Perception Assessment.................................................................................24  4.2  5  USER SURVEY IMPLEMENTATION AND DATA PROCESSING / ANALYSIS ............................................25 

SYSTEM DESCRIPTION ..........................................................................................................27  5.1  FUNCTIONAL NEEDS  ..........................................................................................................27

February 2008 

UTh 

InMoSion: Deployment Process Design 

5.2 

FUNCTIONAL DESCRIPTION..................................................................................................28 

5.2.1  Functionalities Concerning System Users..................................................................28  5.2.2  Functionalities concerning the System application. ..................................................31  5.3  BASIC ARCHITECTURE: SOFTWARE ELEMENTS ..........................................................................33 

5.3.1  Communication Element..........................................................................................33  5.3.2  Interface Element....................................................................................................34  5.3.3  Database Element ...................................................................................................34  5.3.4  Core Algorithmic Element ........................................................................................35  5.4  BASIC ARCHITECTURE: HARDWARE ELEMENTS .........................................................................35 

5.4.1  Application hardware for conventional application needs ........................................35  5.4.2  Communication Hardware.......................................................................................35  6  7  SYSTEM SIMULATION ...........................................................................................................37  PROJECT IMPLEMENTATION.................................................................................................39  7.1  7.2  7.3  EVALUATION DESIGN .........................................................................................................39  SYSTEM PILOT APPLICATION AND CONSEQUENT DATA ANALYSIS ...................................................40  ACTUAL SYSTEM IMPLEMENTATION AND EVALUATION ................................................................41

February 2008 

UTh 

InMoSion: Deployment Process Design 

Executive Summar y 
As  provisioned  in  the  InMoSion  Project  Work  Package  3  deliverables,  this  handbook  is  intended  to  be  used  by  anyone  in  need  of  advice  on  how  to  set  out  or  improve a paratransit transport scheme, either in urban, suburban or rural environment. It  aims  to  assist  in  the  design,  operation  and  evaluation  of  such  systems,  and  it  gives  recommendations of a general nature, based on existing paratransit system examples and  conclusions, as well as expert knowledge collected from InMoSion Project members.  The  content  of  this  Handbook  is  organized  in  accordance  with  the  Phases  necessary for the deployment of a new paratransit system. These Phases and steps are  analyzed to the full extent, so as to facilitate in the decision, design and implementation  process. In  Chapter  2,  the  Scheme’s  Initial  Evaluation  is  being  described,  including  the  choice  of  an  appropriate  area  for  the  system  set  up,  the  definition  of  the  Stakeholders  involved,  the  description  of  existing  Transport  Services,  the  recording  of  the  Transport  Organizations  already  operating  as  well  as  other  public  organizations  related  to  transportation,  and,  finally,  the  Legal  Issues  involved  with  the  onset  of  a  new  transport  scheme.  In  Chapter  3,  having  finished  the  Initial  Evaluation,  the  scheme  is  delineated  in  terms of Goals and Objectives, Scheme structure, Organizational and licensing, Staffing,  Technology, Budget and Marketing.  In  Chapter  4,  the  necessity  for  recording  transport  user  needs  and  customer  potential  appreciation  of  the  propose  system  is  established.  Moreover,  guidelines  for  creating  a questionnaire  are given, along with  instructions on  how to implement a User  Survey and how to analyze data gathered by this Survey.  In Chapter 5, the proposed System is simulated via appropriate software, so as to  establish  certain  operating  parameters,  the  System’s  behavior  in  various  demand  and  service quality scenarios, and viability or profitability or the scheme.  In  Chapter  6,  a  Pilot  Application  for  the  System  is  described,  along  with  what  conclusions need to be derived from it. Moreover, the System begins operation, where the

February 2008 

UTh 

InMoSion: Deployment Process Design 

handbook focuses on evaluation design and objectives,  before and during actual system  operation.

February 2008 

UTh 

InMoSion: Deployment Process Design 

1  Intr oduction 
1.1  The InMoSion Pr oject 
The overall aim of this project is to accommodate a University based Science Shop  (called  InMoSion)  and  to  develop  all  necessary  expertise  and  know­how  for  assisting  communities  with  the  deployment  of  an  innovative  transportation  system  to  meet  the  mobility  needs  of  elder  and  mobility  challenged  Europeans.  The  system  is  a  flexible,  technologically advanced demand  based paratransit system. The InMoSion project  is  be  lead  by  the  University  of  Thessaly  in  Volos,  Greece  and  will  support  at  first  a  Greek  Capodistrian Municipality, the Municipality of Philippi, to deploy a paratransit system in  order  to  enhance  the  mobility  in  the  area.  After  that,  the  InMoSion  project  will  help  communities  across  Europe  and  elsewhere  that  wants  to  investigate  the  potential  deployment  of  such  a  demand  based  paratransit  system.  The  Science  Shop  develops  all  necessary know how through this  initiative and  is creating a core group of students and  researchers that can support free of charge communities through the whole process:  from  conception,  feasibility  analysis  needs  analysis,  requirements  analysis,  system  design,  yield management, deployment, evaluation and maintenance.  It  is  a  well  known  fact  that  Europeans  are  rapidly  aging,  mainly  due  to  the  low  birthrate and the increase in people's lifespan; new technologically advanced and flexible  transportation  solutions  must  be  developed  in  order  to  address  their  constantly  growing  mobility  challenges.  Older  people  are  usually  unable  to  drive  but  prefer  to  live  in  low­  density  suburban  locations.  The  transportation  systems  in  these  areas  are  often  quite  inadequate, which creates serious  mobility problems, especially  for elderly and disabled  people. While the elderly and disabled are the target customers for the proposed Science  Shop, such a service  may  be expanded to any potential traveler  in the  future, given that  the system will be broadly available, to meet their needs. 

1.2  Pur pose and Layout of this Handbook 
This handbook is intented to be used by anyone in need of advice on how to set out  or improve a paratransit transport scheme, either in urban, suburban or rural environment.  It  aims  to  assist  in  the  design,  operation  and  evaluation  of  such  systems,  and  it  gives

February 2008 

UTh 

InMoSion: Deployment Process Design 

recommendations of a general nature, based on existing paratransit system examples and  conclusions, as well as expert knowledge collected from InMoSion Project members.  The  content  of  this  Handbook  is  organized  in  accordance  with  the  Phases  necessary for  the deployment of a new paratransit system. These phases consist of a  number of steps, and are namely the following:  1.  Phase One ­ Initial Evaluation  1.1. Area Profile  1.2. Stakeholders  1.3. Existing Transport Services  1.4. Existing Transport Organization  1.5. Legal Structure  1.6. Scheme Delineation  2.  Phase Two ­ User Needs Survey  2.1. User Survey Design  2.2. Questionnaire Design  2.3. Survey Implementation  2.4. Survey Data Analysis  3.  Phase three ­ System Design Description  3.1. Functional Needs  3.2. Functional Description  3.3. Basic Architecture Software Elements  3.4. Basic Architecture Hardware Elements  4.  Phase four ­ System Simulation  5.  Phase five ­ Pilot Application  6.  Phase six ­ System Implementation  7.  Phase seven ­ System Evaluation

February 2008 

UTh 

InMoSion: Deployment Process Design 

These Phases most of the times will overlap, and are formulated in order to provide  a roadmap for the creation of new paratransit system, not a timetable for it.  In  Chapter  2,  the  Scheme’s  Initial  Evaluation  is  being  described,  including  the  choice  of  an  appropriate  area  for  the  system  set  up,  the  definition  of  the  Stakeholders  involved,  the  description  of  existing  Transport  Services,  the  recording  of  the  Transport  Organizations  already  operating  as  well  as  other  public  organizations  related  to  transportation,  and,  finally,  the  Legal  Issues  involved  with  the  onset  of  a  new  transport  scheme.  In  Chapter  3,  having  finished  the  Initial  Evaluation,  the  scheme  is  delineated  in  terms of Goals and Objectives, Scheme structure, Organizational and licensing, Staffing,  Technology, Budget and Marketing.  In  Chapter  4,  the  necessity  for  recording  transport  user  needs  and  customer  potential  appreciation  of  the  propose  system  is  established.  Moreover,  guidelines  for  creating  a questionnaire  are given, along with  instructions on  how to implement a User  Survey and how to analyze data gathered by this Survey.  In  Chapter  5, the  proposed  System  is  simulated  via  appropriate  software,  so  as to  establish  certain  operating  parameters,  the  System’s  behavior  in  various  demand  and  service quality scenarios, and viability or profitability or the scheme.  In  Chapter  6,  a  Pilot  Application  for  the  System  is  described,  along  with  what  conclusions need to be derived from it. Moreover, the System begins operation, where the  handbook focuses on evaluation design and objectives, before and during actual operation 

All of the above mentioned phases and steps will be analyzed to the full extent, so  as to facilitate in the decision, design and implementation process.

February 2008 

UTh 

InMoSion: Deployment Process Design 

2  Initial Evaluation 
2.1  Ar ea pr ofile 
A general rule of thumb for the area location where the system should be deployed  is finding an area underserviced by current transport schemes, such as a suburban setting,  an  area  with  sparse  villages,  or  a  housing  area  with  abnormal  terrain  and  stip,  narrow  roads.  The  area  covered  by  the  service  must  be  clearly  delineated.  The  needs  of  the  residents and potential passengers should be the deciding factor when identifying the area  that  the  new  services  will  cover.  Political  and  organizational  borders  such  as  municipalities,  districts  and  provinces  will  often  form  the  boundaries  for  operation  and  financing of the public transport system. Nevertheless, access should be provided to other  local centers and points of interest, which are important destinations for public transport  users. It is also important to choose areas without, or with very limited, alternative public  transport  solutions,  otherwise  the  new  service  will  add  unnecessary  competition  to  the  current  providers  and  operators.  New  service  areas  should  complement  those  already  covered. It is also important not to over­extend by including too many dispersed destinations  and over­stretching the service area under consideration. Trying to serve too many areas  and too many people by using an extensive number of vehicles is a common mistake in  these cases which  may  lead the system to an early  breakdown. The  new service should  start with a  few essential destinations and gradually  add  more as  it becomes established  and successful.  Also,  the  demographic  and  socio­economic  profile  of  the  area  should  be  studied,  e.g.  population  structure,  age  profile,  unemployment  rates,  car  ownership  rates.  Good  sources  for this data are usually the  national and  regional statistical services. In an  area  with high car ownership, people without access to a car are usually either young or old. In  an area with low car ownership other target groups can be found.  For  a  general  overview  national  statistics  might  be  sufficient,  but  for  detailed  information  the  use  of  specific  household  surveys  is  recommended.  Information  on  the  modal  split,  dependence  on  public  transport,  destinations,  trip  characteristics,  access  to  telephone etc is crucial for the successful design of the new or improved services. A more 9 

February 2008 

UTh 

InMoSion: Deployment Process Design 

thorough explanation of the necessity and specific aspects of this user survey will follow  later on. Focus groups can further reveal local needs and inadequacies, which may also be  done by monitoring the mobility patterns of a family or a group of people for a specific  period of time.  Another important task is the delineation of the dispersal of population and distance  (e.g. in terms of travel time by car) from main services. A list and display on a map of the  location  and  profile  of  basic  essential  services  (health,  financial,  social,  commercial,  educational,  employment,  recreation  and  schools)  will  be  useful  in  establishing  most  frequent  travel  destinations.  Sorting  destinations  according  to  usual/typical  trip  frequencies  (e.g.  school  and  work  =  daily,  shopping  =  weekly,  local  administration  =  monthly) would also add to the greater picture. 

2.2  Definition of Stakeholder s 
The difficulty of employing paratransit systems in most cases has proven to be the  balance  that  should  be  achieved  between  the  involved  stakeholders.  Those  are  all  the  entities  affecting  the  operation  of  the  system,  and  those  entities  that  have  a  direct  or  indirect interest in its operation. The stakeholders identified are summarized below, along  with the role they play in the deployment of a paratransit system.  2.2.1  Users  The  potential  users  of  the  paratransit  system  could  be  categorized  into  different  groups based on occupation, age, gender, etc. The attitude of each user plays an important  role and is affected by their mobility needs, financial situation, whether they own private  means  of  transport,  trip  purpose  and  origins/destinations.  Students,  housewives,  elders,  disabled and retired people appear to be more willing to use such a service, while tourists  appear to constitute a special category of users. The paratransit system may accommodate  their  mobility  needs  providing  transportation  solutions  of  better  quality  and  cost.  The  users are obviously the  most critical  stakeholders and their perception of the paratransit  system will determine the  market share attracted by  such a  system. The  most  important  parameters determining the market share are the cost and the level of service. The users’  perception needs to be more thoroughly analyzed through a structured questionnaire so as  to broadly quantify the parameters determining the market share.

February 2008 

10 

UTh 

InMoSion: Deployment Process Design 

2.2.2  Operators  The  operator  is  responsible  for  the  efficient  operation  of  the  paratransit  system.  Additionally, he is responsible to take all the decisions related to the level of service and  the  pricing  policy.  The  operator  may  be  a  municipal  entity,  a  private  entity  or  a  Public  Private  Partnership  (PPP).  The  objective  of  the  operator  is  obviously  to  ensure  the  financial  viability  of  the  system  and  depending  on  its  corporate  structure,  to  increase  profit  or  social  benefit.  The  operator  will  be  responsible  for  designing,  deploying  and  maintaining the system. The general impacts of the system on land use, environment and  socio­economics  are  of  interest  from  the  point  of  view  of  negotiating  tax  breaks,  subsidies and cost­sharing schemes. The operator is probably the second most important  stakeholder, as he can determine the pricing policy and level of service that affects users’  perception and ultimately market share.  2.2.3  Government  Local  governments  are  potential  stakeholders  as  they  can  be  the  operator  or  participate in a Public­Private Partnership (PPP) and of course they have to represent the  people  in  general.  In  addition,  they  are  also  responsible  for  the  compliance  with  state  regulations and for any potential subsidies of the system. Finally, local governments are  interested  in  serving  their  constituency,  especially  the  old  and  disadvantaged  that  have  mobility  problems.  Paratransit  can  positively  impact  environmental  problems  and  have  important  implications  on  land  use  and  the  economy.  The  system  may  need  to  be  subsidized  through  taxation  or  participation  from  the  local  market,  which  also  involves  the local, regional and central government.  In most cases, because the implementation of a paratransit system requires a large  amount of money to be invested, the participation of the local or national government in  subsidizing the system would constitute a viable solution especially for the first years of  the system’s operation.  2.2.4  Driver s/Employees  Deploying  a  paratransit  system  influences  all  the  employees  responsible  for  its  efficient operation such as drivers, system operators and administrators. Employees may  be either private employees, owner operators or even taxi drivers that can participate  in  the operation. The employees of the system will also be responsible for the quality of the  provided services.

February 2008 

11 

UTh 

InMoSion: Deployment Process Design 

2.2.5  Local mar ket & Touristic businesses  Local  market  includes  all  the  public  and  private  organizations  like  schools,  hospitals, commercial markets, hotels etc. These entities may benefit from the increased  mobility (in addition to any latent demand) and the flexibility & convenience provided by  the system. The increased economic activity is of interest to these entities and they may  be asked to participate in sharing the cost of the system.  2.2.6  Competition: other Transportation Service Provider s  Other  transportation  service  providers  may  be  the  official  public  bus  system  that  operates in the area, or taxis. The introduction of a new transport system will undoubtedly  affect them. Additionally, because the desired service quality of the paratransit system is  roughly equivalent to taxis’ while the cost remains at lower levels, comparable to those of  buses,  it  is  expected  that  these  operators  will  oppose  to  the  implementation  of  such  a  system.  There  is  also  a  case,  however,  that  the  paratransit  system  accommodates  the  mobility  needs  of  passengers  in  favor  of  the  public  bus  system.  Paratransit  may  be  a  valuable tool to increase the efficiency of the public bus system and this depends on the  type of relationship that will be established between them. On the other hand, paratransit  may also collaborate with taxis. It may form contracts with taxis in order to use them in  cases where the existing infrastructure cannot satisfy the requests in the system. 

2.3  Existing tr anspor tation ser vices in the ar ea 
Existing transportation services  in the area  should be profiled  and assessed, along  with details of local transport providers. All kind of services provided by public agencies,  private  operators  (bus/taxi),  volunteer  services,  community  services  etc.  should  be  included.  Other  important  issues  would  be  already  existing  contracts,  cost,  revenue  and  profitability analyses (wherever available).  Also, the number of public transport runs day and the stops they make should be  displayed on a  map giving details of routes operated. This would help establish a  better  perspective of underserviced areas, or areas where there are adequate itineraries. Not only  is the distance to the nearest bus/train station important, but it is also the number of runs  per day that defines the quality of the service. Finally, distinguishing between private or

February 2008 

12 

UTh 

InMoSion: Deployment Process Design 

public  operators  and  taking  tendering  processes  and  different  types  of  contract  into  account is very useful.  In most countries, it is appropriate for new public transport services to supplement  the existing ones, not to compete with them. Co­modality, which in this case would mean  that  the  new  public  transport  would  provide  a  good  feeder  service  to  those  already  existing, greatly improves accessibility.  Another step in the same direction is to profile and assess use of existing transport  services,  i.e.  identify  transport  needs/patterns  for  different  groups  in  your  area  (e.g.  commuters, children, youth, older people and disabled people.) This is a very critical step  in  the  process,  for  this  knowledge  is  important  for  future  work  with  the  upcoming  transport  scheme.  If  the  new  service  does  not  meet  the  needs  of  the  target  groups, this  could  result  in  insufficient  demand.  Problems  could  even  arise  from cultural  resistance  among the target population to components of the service (e.g. mixing of different kinds  of passengers such as the general public and school children). 

2.4  Existing public or ganizations and tr anspor t or ganizations 
Existing  community  groups,  public  agencies,  contractors/providers  must  be  identified,  along  with  the  organizational  structure  within  the  different  groups  and  agencies.  A  very  important  element  of  the  initial  face  planning  is  the  identification  of  Stakeholders, who were analyzed earlier.  It  could  be  that,  by  law,  the  region  is  legally  responsible  for  public  transport,  but  local  municipalities actually  feel responsible  in terms of  securing  basic social  needs  for  their  citizens  where  financing  of  a  new  rural  transport  service  is  concerned.  Also,  organizations  or  private  companies  could  appeal  against  the  new  service  or  at  least  prevent its implementation, if they fear competition as a result (e. g. other public transport  operators or taxi­operators in the region) or feel that their interests may be violated (e. g.  parents  organizations).  Therefore  it  is  indispensable  to  identify  the  local  situation  of  stakeholders and existing public transport agreements at an early stage of the project and  to  involve  the  people  concerned  in  an  intensive  networking  process  in  order  to  find  a  balance of interests.

February 2008 

13 

UTh 

InMoSion: Deployment Process Design 

2.5  Legal str uctur e 
The legal frameworks and rules put to power for public transport in the area under  question need to be inspected. Moreover, one should make clear if there are special rules  and regulations for licensing. An important question is the opportunity of a small, perhaps  new,  operator  to  access  the  public  transport  market.  Questions  to  be  addressed  in  this  context are:  Ø  Is the market very regulated, are there other competitors?  Ø  Is it necessary to obtain a route license?  Ø  Is there a tendering process for obtaining a license?  Ø  What  are  the  preconditions  for  obtaining  a  license  (financial,  equipment,  education of staff)?  Ø  Is the necessary license based on fixed routes or is route diversion allowed?  Ø  Is the license limited in time?  In  most  cases,  other  legal  questions  also  have  to  be  resolved,  because  innovative  services  often do  not  fit  into  the  conventional  legal  framework.  It  may  be  necessary  to  check  whether  all  components  of  the  service  comply  with  legal  requirements  (e.g.  engaging  volunteer drivers,  mixing of different types of passengers  etc.). In some cases  those  obstacles  can,  probably,  only  be  resolved  with  special  regulations.  Getting  legal  advice  beforehand  if  the  intended  service  does  not  seem  to  fit  into  the  existing  legal  structure would be a wise step. 

2.6  Summar y of the initial evaluation 
The final step of action for the initial evaluation is to summarize the findings and to  have them presented to the Stakeholders, so as to check if anything is missing and if data  needs to be added to the initial evaluation. When presenting the results to representatives  from all relevant stakeholders, getting feedback is obligatory, and, even better, contacting  stakeholders other than those initially identified.  The problems found and the inadequacies must be detailed, and at that point comes  the time to decide whether or not to continue with the analysis or if there  is  no need to  change the current transport situation in the area. The essence of the decision is whether  the  new,  proposed  system  would  add  to  the  overall  level  of  public  transport  service,

February 2008 

14 

UTh 

InMoSion: Deployment Process Design 

therefore being necessary and useful, or not. If so, then the usefulness of the new system  should be quantified by means of a User Survey, as analyzed further on.

February 2008 

15 

UTh 

InMoSion: Deployment Process Design 

3  Delineation of the proposed transpor t scheme 
After the initial evaluation is complete, the next logical step would be to decide on  which of the transport issues identified in the previous steps are going to be addressed, or  which  groups’  needs  the  new  transport  scheme  will  be  linked  to.  The  services  offered  should be tailored to match the needs that emerged in the initial evaluation. For example,  one can decide on implementing a transport serviced based on small, on­demand vehicles  in specific time periods and in low­demand regions, that would complement the already  existing regular bus service.  The scheme’s delineation should include the following:  Ø  Goals and Objectives  Ø  Scheme Main Structure  Ø  Scheme Organization – Legal Permission / License  Ø  Plan of Action  Ø  Staffing Needs  Ø  Appropriate Technology and Equipment Cost  Ø  Budget / Contracting Services  Ø  Marketing Plan 

In more detail, the new, allegedly improved, service need have specific goals and  objectives. The objectives under definition should be clear, realistic and achievable, and  each objective’s goal should not be overambitious. For example, it is definitely easier to  extend operating hours, trip frequency or service characteristics, than to cut it down later  due  to  financial  or  funding  reasons.  Moreover,  the  existence  of  numerous  groups  of  stakeholders entails the appearance of different levels of expectations for each objective.  Bearing in mind the transport needs to be addressed and objectives defined earlier  on, the  main characteristics of the service, which  is the  main  structure of the scheme,  are ready to be defined. In simple terms, the different stakeholders can now agree on how  the  new  system  will  work  and  what  the  service  attributes  will  be.  Co­modality  and  integration with already existing services is essential. For example, a taxi, a school bus or

February 2008 

16 

UTh 

InMoSion: Deployment Process Design 

a  health  transport  vehicle  can  also  be  used  as  a  public  transport  vehicle.  This  strategy  avoids investment in additional vehicles and equipment and makes the transport solution  affordable in the long run. Moreover, the service level and service area should be kept on  a small, local scale at first, in order to avoid unforeseen expenses. Extensions can easily  be made once the service is already running smoothly. For the same reasons, the scheme  customers  should  be  limited  to  local  demand  and  operating  at  regional  level  should  be  avoided, but one must make sure that the transport system coincides with regular bus or  rail services in order to provide regional connections.  To be more explanatory, the type and scale of transport services under plan must be  explained in detail. Description of the proposed services should include: ·  operating hours ·  booking hours ·  type of service (demand­responsive, social car scheme, fixed route, etc.) ·  information regarding the proposed service (schedules and frequencies) ·  nature and numbers of potential passengers ·  fare structures ·  types of vehicle to be used (owned, borrowed, contracted in, passenger capacity,  level  of  access  for  people  with  reduced  mobility,  garaging  and  maintenance  requirements) ·  Routing of services / area of coverage ·  Scheduling and co­ordination of the services 

Another  important  course of  action  is  to  define  how the  intended  public  transport  service will be  organized.  As a  first step, change  is  not an end  in  itself,  so  the scheme  would better off cope with the existing legal and organizational framework. Categorizing  the service as a pilot demonstration may help allow exceptions. That is, if arguments for a  good transport solution are strong, higher authorities  may  convince  lower ones to allow  exceptions. When the structure of a new public transport service differs from the standard  legal  organizational  structures,  it  is  highly  recommended  to  clear  any  potential  legal  problems beforehand, and apply for appropriate legal permission and license.  An outline of the plan of action  regarding the organization will act as a road map,  before  and  during  the  operation  of  service.  This  plan  should  also  be  followed  by  a

February 2008 

17 

UTh 

InMoSion: Deployment Process Design 

timetable,  on  a  month­to­month  basis,  so  as  to  form  boundaries  for  system  design,  deployment and operation. The work to be done must be thoroughly detailed, and time­  planning must start at an early stage, since a number of different steps can take time, e.g.  delivery of buses, changing of laws, legal exceptions and permit.  Another  issue  is  the  manning  /  staffing  of  the  transport  scheme  strategic  and  operational  organization.  On  the  Board  of  Management  expertise  and  experience  is  needed in the following sectors: ·  management of transport projects ·  financial management ·  IT expertise ·  community development ·  local knowledge  Essential  staffing  requirements  include  a  manager  or  a  managerial  board,  administrators, dispatchers and drivers. Training needs are bound to emerge, not only for  drivers and operators. This  is another important issue that should  be dealt with,  for  it is  not sufficient to design the system’s operation, but it has to be.  Next,  it  is  necessary  to  identify  the  appropriate  technology  that  will  assist  in  fulfilling the scheme’s objectives. High­tech solutions are useful as  long as devices and  equipment  are  already  in  place  and  can  be  used  at  low  additional  cost.  Phones,  for  example,  exist  almost  everywhere  and  can  be  handled  by  volunteers,  taxi  drivers  etc.  without  any  special  qualification.  Also,  the  availability  of  mobile  /cell  phones  and  the  existence of internet connections is needed, if they are going to be used for ordering and  delivering  of  services.  Moreover,  it  would  be  beneficial  to  investigate  if travel  dispatch  centers which could be used already exist in the area.  Cost  for  any  technical  equipment  should  always  be  in  an  acceptable  ratio  to  its  benefit  (e.g.  number  of  passengers  transported).  Potential  users  of  the  public  transport  system must be able to use the system. If, for instance, computer availability is low it is  not appropriate to implement internet booking. Costs of operating a high tech system are  not to be underestimated. Real­time information systems are not only expensive to set up,  but there are also ongoing operating costs in ensuring that the information is provided in a  consistent,  accurate  and  up­to­date  manner.  Funding  is  often  available  for  the  capital

February 2008 

18 

UTh 

InMoSion: Deployment Process Design 

costs  of  setting  up  a  system,  but  less  readily  available  for  the  costs  of  operating  the  system on a day­to­day basis.  The managerial body should now be ready to calculate expenditure and income  (budget)  at  a  general  level.  Expenses  can  be  divided  in  administrative,  capital  and  operational costs:  v  Administrative costs entail advertising and marketing, board expenses, capital  expenses, personnel recruitment, training and salaries, office expenses and  consumables.  v  Capital costs entail vehicle acquisition/renting/contracting, technology equipment  purchase and maintenance.  v  Operating costs entail drivers’ wages, vehicle leasing, fuel and maintenance  /consumables, insurance and cleaning.  If contracting ser vices are going to be used, for examples if vehicles will not be  bought but local taxis will be used instead, the tendering process for these services must  be  determined.  A  budget  should  be  specified  for each  different  service,  and  one  should  ensure  that the  notice  of  the  tender  is  widely  available  to  all  potential  bidders,  and  that  some  of  the  existing  operators/suppliers  can  meet  the  tender  requirements,  so  that  they  can compete for the contract. Procedures for submitting the bid and the evaluation of all  bids must be clear to all potential bidders and to the bid evaluation committee.  On  the  other  hand,  sources  of  income  could  be  fares,  service  contracts,  public  subsidy,  on­board  advertisements.  Long­ter m  financing  is  crucial.  National  funding  programs, for example, sometimes tend to provide start up financing only, but long­term  financing  must  be  secured.  Subsidies  for  rural  systems  are  often  a  problem  because  the  cost  per  trip  is  very  high.  It  is  essential  to  gain  political  or  market  support  in  order  to  ensure the  long­term operation of the  new transport service. The  benefits of the  service  must, therefore, be emphasized in a comprehensible way to gain support from, preferably,  all political parties or social groups, which helps avoid any discontinuation of the support  after elections.  Finally, a  very  important  aspect of the whole procedure  is that of promoting the  proposed service. Mar keting needs time and has to be a permanent process. It often takes  time for the target group, the potential customers of the scheme, to get familiar with the  new  service  (this  is  often  due  to  operating  details,  such  as  trip­booking  in  the  case  of
February 2008 

19 

UTh 

InMoSion: Deployment Process Design 

demand­responsive  services.)  and  for  general  acceptance  to  grow.  Marketing  has  to  be  focused  on  the  target  group of  the  service,  as  well  as  lobby  groups  (e.g.  policy  makers  and organizations which can promote the new service to the target group), not to mention  the stakeholders as a total.

February 2008 

20 

UTh 

InMoSion: Deployment Process Design 

4  User  Sur vey Design 
The  most  important  issue  that  should  be  taken  into  consideration  in  deploying  a  paratransit system is the perception of the users. The most obvious reason for that is the  level  in  which  the  users  feel  satisfied  by  currently  operating  transport  systems.  In  case  that the users cannot see the need for the introduction of a new system or they have not  completely understood the advantages and the disadvantages it entails, they would be less  likely to use the new system. This proves that it is crucial to identify the market potential  of the area in which the new system is going to be deployed.  In  addition,  if  the  results  of  a  survey  like  this  are  positive,  then  the  paratransit  system will be easier to deploy in terms of financial support by the local government or  private  entities.  But  mostly,  the  purpose  of  this  survey  is  to  capture  all  the  critical  elements  that  need  to  be  taken  under  consideration  in  the  designing  phase  and  define  some  crucial  steps  in  the  phase  of  deploying  a  paratransit  system.  Moreover,  all  these  issues are of  interest to the stakeholders  in their  decisions to deploy or not a paratransit  system  because,  after  all,  the  viability  of  the  system  depends  on  these  elements.  Apart  from that, and taking as a fact that the decision to implement a new transport scheme has  already been taken, the survey will clarify the exact extent of the area to be serviced (both  in terms of geographic boundaries and of consumer target groups).  In  many countries where paratransit systems  have been already deployed, surveys  were  usually  conducted  only  after  the  system  was  in  operation.  Thus,  they  wanted  to  capture the perception of the users in terms of enhancing the existing paratransit system  and  provide  services  of  better  quality.  The  majority  of  these  questionnaires  were  conducted  on­board  or  even  by  phone.  Additionally,  many  questionnaires  have  been  presented that deal with the  issue of transportation of  handicapped persons and how the  paratransit system can be adapted in order to provide quality services and easy access to  disabled. 

4.1  Design of the questionnair e 
The most widely used method in order to identify the market potential is to conduct  a survey  by questionnaire.  While some of the studies on DRT provide results of survey  analysis, few provided the full survey questionnaires. A representative yet thorough set of

February 2008 

21 

UTh 

InMoSion: Deployment Process Design 

parameters from different DRT survey analyses is collected and can be used to create the  questionnaire to be used. This questionnaire is applicable in all cases, whether the survey  site is an urban or a rural area.  The questionnaire includes six parts: ·  Part A­ User Characteristics ·  Part B­ Trip Characteristics: ·  Part C­ Transit System Characteristics: ·  Part D­ Paratransit System Characteristics and Preferences: ·  Part E­ Technological Aspects ·  Part F­ Perception Assessment  The  last  part  is  aimed  to  assess  the  first  perception  of  the  system  through  the  scenario and possible differences after detailed questions on system characteristics. This  part  even  includes  the  repeat  of  some  basic  questions  and  concepts  from  previous  sections.  The parameters that affect the success of DRT systems and surveys are listed below  with  brief  explanations  and  a  proposed  questionnaire  is  presented  in  the  following  sections.  4.1.1  Part A­ User Characteristics  The first part includes questions about the participant characteristics such as age,  occupation,  employment  status,  etc.  A  question  about  the  Zipcode  of  the  respondent  is  added to see spatial distribution of the potential users later. Age and gender information is  collected, and age groups intervals are decreased in the survey to understand attitudes of  different  age  groups  to  the  transit  system.  The  respondents  are  asked  about  their  employment status to find out patterns of their work­based trips. Education  level of the  respondent  is  also  an  important  parameter  generally  affecting  income  level  and  technology use, which are also asked in the first part of the questionnaire.  Even though the inverse relation between level of income and transit ridership is  commonly  observed  in  other  studies,  collection  of  income  level  of  the  participant  is  needed for further studies of DRT demand market segmentation. In order to capture the  total  number  of  trips  for  a  household  in  the  second  part, the  household  size  is  asked  in  this part.

February 2008 

22 

UTh 

InMoSion: Deployment Process Design 

Also,  the  respondent’s  familiarization  with  information  technologies  is  included  so  as  to  determine  the  level  of  service  and  design  of  the  scheduling  section  of the  new  paratransit system. This question is also aimed as a control parameter about questions on  scheduling options in the last part of the questionnaire. The special needs of elderly and  disabled people are also taken into consideration and asked as a separate question.  4.1.2  Part B­ Trip Characteristics:  The second part of the questionnaire deals with usual/habitual household trips of  the respondents. A weekly household trip plan may be proposed instead of an individual  respondent. The main motivation behind this is to capture a) diversity of trip purposes, b)  trip  chaining  behavior  and  c)  total  number  of  travelers  in  each  trip  so  that  costs  calculations  and  total  potential  can  be  performed  more  accurately.    First  of  all,  the  available to the costumers modes of transport are inquired, which can be customized for  the survey region.  If the  respondents  are  asked  about  household  trips  instead  of  personal  trips,  the  number  of  travelers  taking  a  trip  is  asked.  Secondly,  the  cost  section  is  made  more  specific by asking if there are extra costs in the trip such as parking costs, which can be  crucial  for  urban  regions.  Thirdly,  if  the  mode  used  by  a  household  is  not  desirable  to  them, their desirable means of transport are asked. Then, the specific trips the respondent  undertook  in  a  specific  past  time  period  is  asked,  along  with  a  separate  question  about  average (weekly usually) travelling habits.  4.1.3  Part C­ Transit System Characteristics:  The third part should contain questions about transit system characteristics such as  frequency  of  the  use  of  public  transport  system,  perception  of  the  existing  public  transport  system and  the  reasons  to  use  public  transit.  The  respondents  are  asked  about  their acceptable waiting times for public transit. Since willingness to wait is correlated to  willingness to use a transit system (Anspacher et al, 2004), this may  in return affect the  total demand. The distance to the nearest transit  stop should  also  be  asked, which  is an  important  factor  affecting  willingness  to  use  transit  services,  especially  in  the  case  of  disabled people (Golledge et al, 1996, Anspacher et al, 2004).  4.1.4  Part D­ Paratransit System Characteristics and Prefer ences:  In  the  fourth  part, the  new  transit  –in  this  case  the  proposed  paratransit  system­  must be explained to the participant. That includes clarification of the way the costumer

February 2008 

23 

UTh 

InMoSion: Deployment Process Design 

may  reserve  a  trip,  the  proposed  levels  of  service  (but  not  in  strict  detail,  since  at  this  point they can’t have  been specified to the  full extent), the available  means of payment  and  the  cost  of  a  trip  (again,  a  rough  estimation  of  it).  Then,  the  desirability  and  perception  of  the  system  is  sought  through  some  questions  that  include  level  of  willingness to use and pay the proposed paratransit system,  acceptable  number of stops  during  the  ride,  in­advance  scheduling  requirements,  and  even  qualities  of  drivers/operators. As willingness to use and pay for trip change with distance (and travel  time), the users’ preferences should  be asked  for short trips (i.e.  less than 5 km)  versus  longer trips (i.e. 5­15 km) separately.  4.1.5  Part E­ Technological Aspects  The fifth part is included to represent parameters that would affect and depend on  the design of the paratransit system under consideration as well the user characteristics in  the  region  on  focus.  It researches  for  technological  availability and  users'  ability to  use  these technologies. The respondents are asked about which technologies should be made  available in this system for scheduling their trips, and for notification about their pick­up.  Then, their opinion about benefits of this system is asked.  4.1.6  Part F­ Per ception Assessment  Finally,  they  should  be  asked  again  if  they  use  this  system  to  check  if  they  have  changed  their  mind  at  the  end  of  the  survey,  which,  taking  into  consideration  that  the  actual operation details are explained throughout the questionnaire, is very likely to have  happened.  Furthermore,  a  general  and  aggregate  perception  of  the  system  should  be  sought through two questions: expected benefits to a) the user and b) the society. 

The  above  mentioned  proposed  parts  of  the  questionnaire  are  a  more  general  and  more complete form of questionnaire which is applicable to both urban and rural places.  But as the length and easiness of survey questionnaire is important to the success of such  an analysis, some parts of the proposed questionnaire can  be  left out or combined  for a  specific  location.  But  if  such  modifications  are  done  over  a  more  general,  standardized  questionnaire, it may still be possible to compare survey results from different locations.

February 2008 

24 

UTh 

InMoSion: Deployment Process Design 

4.2  User  Sur vey Implementation and Data Pr ocessing / Analysis 
For the survey to be implemented, one must decide on the sampling method (which  in most cases, as mentioned earlier, is likely to be a questionnaire) and then focus on the  sample population details.  First of all, the representation of the whole population  in the  survey  must  be  guaranteed,  so  as  to  have  a  better  understanding  of  all  the  area’s  inhabitants.  In  that  direction,  sampling  errors  and  sampling  bias  must  be  minimized,  if  not eliminated.  The population groups, whose representation in the survey needs to be proportional  to the members bearing the groups’ characteristics, are: · Sex · Age · Occupation / attribute (i.e. student, housewive) · Residence location (Suburbs, town, small village) · Special needs / mobility disabilities 

Next,  one  must  decide  on  the  sample  kind  (simple  random  sample,  stratified  random  sample,  cluster  random  sample,  systematic  sample).  Having  ensured  that  this  sample is representative of the whole population, the next important task is to make sure  the recorded data are accurate. That means that the personnel conducting the survey has  to have the necessary knowledge of the procedure and of the system design so as to guide  people  under  interview  into  understanding  the  questions  they  are  responding  to  and  answering  accordingly.  The  same  people,  the  survey  conductors,  are  responsible  for  minimizing the sampling error and bias.  When  the  survey  has  been  conducted,  it  is  very  important  that  the  information  gathered from the survey be stored in a database for easier processing. At this point, it is  very important to accurately convey the recorded answers from the questionnaires to the  database,  for  any  mistake  at  this  point  may  alter  the  conclusions  to  be  drawn  from  the  processing of the data.  Data analysis  should  focus on the some or all of  the  following  issues, concerning  the population’s transportation habits: ·  Nature of trips (work, education, healthcare, shopping, leisure)

February 2008 

25 

UTh 

InMoSion: Deployment Process Design 

·  Frequency per kind of trip ·  Trip dependency on sex (male, female) ·  Trip dependency on vehicle type ·  Trip dependency on date and time ·  Trip dependency on subjects profession ·  Trip dependency on markets 

Graphic  representation  of  the  above  data  can  significantly  improve  managerial  insight in potential target groups for the transport system. 

When it comes to the proposed transport scheme, the following issues, concerning  the population’s willingness to replace its current means of transportation in all or some  of its trips with the new system, should be analyzed: · Ticket price, in relation to existing means of transport · Reservation  interval  (how  soon  ahead  would  they  be  willing  to  place  a  reservation) · Waiting time before the trip begins · Travel time, again in relation to existing means of transport 

The  above  analysis  will  specify  how  the  various  user  target  groups  perceive  the  proposed transport scheme, and how would the system’s components and variables affect  their  willingness  to  use  it.  Again,  this  analysis  is  made  in  conjunction  with  the  population’s sex, age and properties. This will transform a general willingness to use the  system’s services into actual traveler numerical projections.  The challenge  is to estimate the demand  for service and service rates, which  vary  across markets (types of passengers carried) and geographic settings and are affected by  vehicle  size, operating  strategies, and service quality. There  is also day­to­day  variation  in  demand  for  service  and  in  operating  conditions  that  makes  the  problem  even  more  complex.  Furthermore,  the  demand  experienced  will  be  a  function  of  actual  service  quality, and thus there is an ongoing equilibrium process

February 2008 

26 

UTh

InMoSion: Deployment Process Design 

5  System Descr iption 
Having  delineated  the  scheme  and  analyzed  the  potential  customers’  appreciation  towards it, it is now time to describe the system in terms of needs should be covered by it  (functional  needs)  and  by  which  functionalities  these  needs  will  be  covered.  Moreover,  the systems architecture, in terms of both software and hardware, is described 

5.1  Functional needs 
In  the  following,  all  the  needs  that  ought  to  be  covered  by  the  on­demand  paratransit system under implementation are presented: ·  Trip Booking. Because of the absence of fixed routes, customers will need to book  for a trip. Various Booking procedures should be offered to the users. For example, web  interfaces, a  live operator, cell  phone short messages or even automated phone  services  should  be  provided  to the  users.  Booking  procedures  should  be  easy  to  use  and  always  available. ·  Definition of pickup or deliver times. The proposed system should offer users the  ability to  either  choose  the  time  they  want  to  depart or the  time  by when  they  want  to  have arrived at their destination. ·  Definition  of  Maximum  Ride  Time.  Maximum  ride  time  is  a  critical  parameter  concerning the user satisfaction. The proposed system should offer the ability to select it.  If  operational  reasons  render  this  impossible,  the  system  should  inform  the  users  of  the  worst case scenario, i.e. the maximum time their trip will last. ·  Definition of specific transportation needs. Specific features should be offered on  demand by the application in order to satisfy user needs. One shouldn’t forget that people  with disabilities or elderly people will by default be among the system’s users. ·  Notifications.  Because  of  the  system  concept,  users  don’t  know  in  advance  the  precise  time  of  vehicle  pickup  and  deliver  time.  That  problem­user  need  should  be  addressed with by a notification system. Notification system is responsible to notify users  about pickup times, delivery times and other relevant issues

February 2008 

27 

UTh 

InMoSion: Deployment Process Design 

5.2  Functional Descr iption 
In this section we define all the appropriate functions that should be offered by the  system  in  order  to  satisfy  the  aforementioned  needs  and  services.  In  general,  we  categorize those functions in the following two function categories. This categorization  is necessary in order to define system functionalities from different views.  5.2.1  Functionalities Concerning System Users  In the first category we describe all functions that the system should offer to system  users. As such we may define: ·  Customers ·  Operators ·  Administrators ·  Other Users with specific needs (for example vehicle drivers or vehicle owners)  5.2.1.1 Customers'  Functionalities  In  this  paragraph  we  define  all  functions  that  should  be  offered  by  the  system  to  customers. ·  Trip Booking. Customers should be able to book a specific tip. That functionality  should be provided by the use of various communication means. Human operators can be  used to get all trip demands orders. Additionally, mobile phone and web services should  be  provided  in  order  to  offer  that  functionality  to  more  technologically  educated  users.  An  IVR  (Interactive  Voice  Response)  can  be  used  also  in  order  to  provide  that  functionality at the times where operator is not available or the web services are difficult  to  use  (by  elderly  people,  for  example).  The  process  should  be  easy.  At  the  time  of  booking procedure, the customer defines origin and destination, pickup and deliver time  windows  and  some  specific  requests  concerning  the  trip  itself.  The  system  responds  within few seconds about the acceptation or rejection of that trip request. Furthermore, it  should  return  to the  customer  a  unique  number  that  corresponds  to that trip  request, or  another method of trip identification that should be used for the confirmation process. ·  Trip  Cancellations.  Customers  should  be  able  to  cancel  a  trip.  Cancellations  use  the same communication means as the trip booking. Customers provide to the system (via

February 2008 

28 

UTh 

InMoSion: Deployment Process Design 

operator or  web)  the  previously  given  confirmation  number  and  the  system  cancels  the  appropriate request. ·  Location  information.  Location  info  is  critical  due  to  the  necessity  of  knowing  where  each  vehicle  is  located.  That  functionality  is  offered  by  the  system  through  GPS  trackers.  Each  vehicle  should  be  equipped  with  a  GPS  tracker/terminal and  its  position  should  constantly  be  projected  on  maps,  so  as  for  the  vehicle  fleet  to  be  managed  effectively. ·  Notifying  Messages.  Notification  is  a  critical  factor of  the  system operation.  The  lack of fixed routes creates the necessity to have a notification system that is responsible  to  notify  customers  about  the  vehicle  approaching  time.  Mobile  phones  SMSs  (due  to  extensive use of mobile phones by the general population), pre­recorded voice mail, web­  mail or even live operators (though that would entail a major investment in maintaining  the  necessary  personnel)  may  be  used  in  that  case.  When  a  vehicle  approaches  the  predefined pickup or deliver point, all customers  engaged to that  specific point  must  be  notified. ·  Payment.  Payment  services  should  be  offered  to  the  customers  via  standardized  procedures. For every trip, a customer may pay to the driver. Alternatively, the customer  could  pay  an  accumulated  amount  over  a  period  of  time  he  used  the  service.  Other  methods should be considered in order to provide more flexible ways of payment .  5.2.1.2 Administrative Functionalities  In  this  paragraph  we  define  all  functions  that  should  be  offered  by  the  system  to  system administrators. ·  System User s Handling (all system users including operators). The system should  allow the creation of users and the assignment of specific tasks to every user.  All users  are  created  by  the  System  Administrator,  who  is  the  default  user.  Users  can  be  categorized by the assigned tasks (for example, Operators or Vehicle Owners). ·  Vehicle Handling. The administrator should be capable to handle vehicles on every  aspect. For example to add, remove and alter the characteristics of vehicles on the system.  That  ability  is  crucial  because  the  administrator  has  the  responsibility  to  provide  the  system with the vehicles fleet necessary in order to constantly satisfy customer needs.

February 2008 

29 

UTh 

InMoSion: Deployment Process Design 

·  Customers Handling. The administrator should be capable to handle customers on  every  aspect.  Technically  speaking,  customer  handling  is  the  Operator’s  responsibility,  but the administrator has the final responsibility for customer database, plus specific tasks  concerning the pricing policy for every customer. ·  System  Parameters  handling.  The  administrator  is  responsible  for  the  modification  of  system  parameters.  By  the  term  system  parameters  we  mean  those  parameters  that  heavily affect  the  system,  such  as  maximum  user  ride  times,  maximum  user allowable deviation from the shortest paths etch. ·  Monitoring Functions. Monitoring  functions are activated and deactivated by the  administrator.  Due  to  security  reasons,  the  administrator  should  have  the  ability  to  activate monitoring on specific (or all) vehicles. ·  Notifying Functions. Notifying is the way that the system communicates with the  customer.  The  type  of  communication  and  the  frequency  of  communication  should  be  specified by the administrator. ·  Itinerary Handling. Administrator should  have the ability to change the  itinerary  for specific reasons (for example when a road is unavailable etch)  5.2.1.3 Operators Functionalities  In this paragraph we define all functions that should be offered by the system to the  system operators. System operators are the live link/interface between customers and the  system.  Basically,  the  operator receives  all  customer  requests  concerning  trips,  answers  questions and runs the system, which produces routes for the same or next day operation. ·  Trips  Handling.  The  operator  –  by  the  use  of  different  communication  means  –  receives all customers request, responds to the customers for the tickets availability and at  times may negotiate with customers in order to find more satisfying solutions.  Finally, he  provides customers with the appropriate information in order to use the system. ·  Routes  Handling.  At  the  end  of  the  day  (or,  in  an  online  system  version,  at  the  same time), the operator should produce the itinerary for the next day and disseminate it  to the vehicle drivers. ·  Customer Handling. During system operation, the operator should have the ability  to add and change a customer’s information.

February 2008 

30 

UTh

InMoSion: Deployment Process Design 

5.2.1.4 Specific Users Functionalities  In  this  paragraph  we  define  all  functions  that  should  be  offered  by  the  system  to  other system users, like drivers and system owners. ·  Vehicle  Handling.  Drivers  –  vehicle  owners  should  have  the  ability  to  add  a  vehicle,  to  change  vehicle  operation  times  and  many  other  parameters  concerning  the  vehicle they own or drive. ·  Routes.  Every  driver  –  vehicle  owner  has  the  ability  to  get  the  itinerary  that  concerns his vehicle. 

5.2.2  Functionalities concerning the System application.  In this category we define what kind of functionalities the system must have at the  application level. Four different application elements can be identified and are necessary  for  the  application’s  operation.  Each  one  cooperates  with  the  others  in  a  vertical  and  horizontal way of action. ·  ·  ·  ·  Operating Web Interface Mapping Functions Reporting Functions Algorithmic Functions 

5.2.2.1 Operating Web Interface  The  application  for  the  system  should  be  a  web  application.  The  access  to  the  application should be made possible from every point where there is an available internet  connection. The web application should provide functionalities such as: ·  Secure Entry. Securing the entry point to the application is a critical point. Users  can enter the system using a unique and identifiable combination of a login name and a  password.  This  combination  contains  all  the  appropriate  information  concerning  the  access rights and the available road networks that the user is granted to use. ·  Networ k  Selection.  The  application  should  be  designed  to  support  unspecified  number of instances in different situations. Every system instance is another road network  together with features that characterize it.

February 2008 

31 

UTh 

InMoSion: Deployment Process Design 

·  Configurable  Menu  Operations.  The  application  menu  should  be  fully  configurable  depending  on  who  is  accessing  the  application.  That  functionality  is  necessary  due  to  the  need  of  different  user  entries.  For  example,  an  operator  should  handle all menu items that are relative to operator jobs.  5.2.2.2 Mapping and Road Networ ks  The application may use commercial free maps in a very extensive way, instead of  implementing  a  tailor­made  GIS  system.  As  commercial  free  maps  we  define  maps  provided to the public via a major provider such Google maps and Microsoft maps. Those  maps  can  be  used  as  reference  in  order  to  construct  road  networks,  as  a  projector  for  itinerary  routes  and  as  a  background  for  monitoring  services.  The  following  paragraph  gives a detailed description of specific mapping functions: ·  Use of non Commercial Maps as a r eference. Currently maps are offered for free  at  least  from  two  vendors  (Google  &  Microsoft).  Those  maps  are  under  continuous  update. The application may use those maps and the provided API’s in order to use them  as  a  reference.  The  term  reference  means  that  one  can  use  those  maps  to  create  road  networks via a simple procedure. ·  Use  of  maps  as  route  projectors.  During  operation,  application  produces  itineraries  for  all  vehicles.  In  order  to  provide  users  with  a  visual  perspective  of  the  appropriate route, the application should provide the necessary functionality by projecting  routes on maps. ·  Use  of  maps  for  monitoring  purposes.  Another  important  issue  of  the  system  application  is  the  monitoring  process.  Monitoring  is  a  main  concern  for  administrators,  vehicle  drivers  or  even  single  users  (like  parents).  The  application  should  offer  that  functionality based on maps.  5.2.2.3 Reporting Functions  Reporting  functions  are  a  necessity  for  every  application.  The  most  important  reports that could be produced by the application are described in the following table: ·  Customer Reporting. Reports concerning customers:  1.  Customer booking frequency  2.  Customer historical data  3.  Customer behavior (cancellations, no shows etch)

February 2008 

32 

UTh

InMoSion: Deployment Process Design 

These  reports  could  prove  to  be  valuable  during  the  study  of  user  behavior  for  future system adjustments. ·  Vehicles Reporting. Vehicles Reporting includes reports concerning:  1.  Vehicles Usage  2.  Vehicles dependence on other factors ·  Trips Reporting. Trips Reporting includes reports concerning:  1.  Total  operating  Duration  in  order  to  determine  the  necessary  service  operating  period  2.  Total  Distance  covered  by  vehicles  fleet.  What  is  the  total  distance  covered  in  order to satisfy all users  3.  Total operation costs for a specific time Period  4.  Profits(loss) for a specific time Period  5.  Service Quality factors such as deviation percentage from the shortest path  6.  Cross reporting factor (Service Quality Vs Price) 

5.3  Basic Ar chitectur e: Softwar e Elements 
The  necessary  software  elements  are:  Communication  Element,  Interface  Element, Database element, Algorithm element.  5.3.1  Communication Element  The  Communication  element  contributes  to  the  system  within  the  necessary  functionality concerning all communication procedures. The proposed paratransit system  is  bound to be heavily depended on communications. Because of  its concept  – no  fixed  routes, no fixed bus stops – every interaction between a customer and the system is going  to be through communication systems. All customer demands for a trip will go through a  land line, a cell phone or the internet to the system. On the other hand, the system should  notify customers when the vehicle on which they will board approaches. That shows the  vital role the communication system plays.

February 2008 

33 

UTh 

InMoSion: Deployment Process Design 

Communication  subsystem  connects  directly  with  the  interface  and  database  elements. Any information that is delivered to the interface element from other elements  such  as  database  or  algorithmic  elements  should  be  transferred  to  the  Communication  element.  For  example,  during  trip  operation,  when  the  vehicle  approaches  pickup  or  deliver point, every customer related to that point  may  be  notified  via SMS or by other  means of verbal communication.  5.3.2  Inter face Element  This  element  contributes  to  the  system  within  the  necessary  functionality  concerning all interfacing procedures. The term “interfacing” includes all the information  interchange  procedures  at  the  point  where  a  demand  is  made  to  the  system.  Interface  interacts  with  the  communication  element,  the  database  element,  and  the  algorithmic  element.  Many  events  produced  by  the  communication  element  will  be  guided  to  the  interface element.  The Interface element just activates or deactivates the algorithm execution, without  providing any information to the algorithm or vice­versa. When the algorithm is activated  by  the  interface,  it  needs  data.  Those  data  come  through  the  database.  The  database  provides  the  algorithm  with  vehicle  number  and  types,  the  road  network,  and  the  trip  demands.  When  the  algorithm  finishes,  it  returns  the  proposed  route/itinerary  to  the  database.  5.3.3  Database Element  This  element  contributes  to  the  system  by  offering  the  storage  procedures  to  the  system. Storage procedures are critical in order to support all data processing needs. The  system should  be reliable  and adaptive enough  in order to support all  necessary storage  needs.  Database is fed by the Interface. Every customer demand is stored to the database,  and  whenever  the  interface  needs  to  inform  users  or  the  operator  with  the  appropriate  information,  it  is  fed by the database. Moreover, when the algorithm  is activated by the  interface, it needs data. Those data come through the database (p.e. vehicles number and  types, the road network, and the trip demands). When the algorithm finishes, it returns the  proposed route/itinerary to the database.

February 2008 

34 

UTh 

InMoSion: Deployment Process Design 

5.3.4  Core Algorithmic Element  That element contributes to the system by offering the necessary intelligence that is  required  in  order  to  always  produce  optimized  solutions.  That  element  is  completely  hidden to users and operators. Operators just activate or deactivate the algorithm in order  to get the appropriate solutions. 

5.4  Basic Ar chitectur e: Har dwar e Elements 
In this section all the appropriate hardware elements that are necessary to setup the  system will  be  described.  Hardware  is  separated  into  two  different  categories.  The  first  category  includes  necessary  hardware  for  conventional  application  needs,  while  the  second category includes hardware for the application’s communication needs.  5.4.1  Application hardware for conventional application needs  Required hardware for the system application should be selected in order to provide  maximum  functionality  and  maximum  usage  of  every  available  resource.  The  main  conventional application hardware elements are: ·  A Server, to provide for all system services. The Server should be fast enough, very  reliable and well modularized in order to support all application functions for large time  periods without malfunctions and with minimum downtime. ·  Data  storage  units,  which  should  be  extremely  reliable  and  tolerant  to  failures  because  they  are  used  continuously  by  the  application  (trips  handling,  reporting  procedure,  continuous  use  of  the  road  network).  Moreover,  there  should  be  adequate  provision for multiple backup units, for emergency system recovery after a failure or for  offline recovery. ·  Fast Internet Connections, due to extensive usage of commercial­free maps (which  are a cheap and reliable alternative to building a tailor­made GIS system).  5.4.2  Communication Hardware  Communication hardware is the necessary hardware to be used for the appropriate  demand  insertion  and  notifying  communication  procedures  between  the  system  and  its  customers.  The  Application  should  use  well  known  types  of  communication  for  notification  purposes  in  order  to  avoid  extra  infrastructure  dedicated  to  the  system.  Mobile  phones  with  GSM  and  GPRS  connections,  along  with  GPS  functions  should  be  supported also in order to provide notification and monitoring procedures. In detail:

February 2008 

35 

UTh 

InMoSion: Deployment Process Design 

·  Mobile  phones  can  be  used  as  the  gateway  between  the  application  and  the  customers. Due to various  system states,  messages  may  need to be  sent  to notify  users.  Mobile  phones  should  be  selected  for  that  use  because  of  their  extensive  use  by  the  general population and network availability provided by various phone companies. ·  GPS devices will be used as application agents to keep constant track of the present  situation  of  the  vehicle  fleet.  Monitoring  procedures  that  will  be  offered  by  the  application to customers, operators, drivers etch will be available through the use of GPS  devices.  In­vehicle  terminals  with  GPRS  or  3G  connection,  along  with  GPS  guidance  capabilities, will also be necessary for route dissemination between the operator and the  drivers. Whether the system will  be online or the routes will  have been decided the day  before,  the  driver  still  needs  to  be  informed  of  his  itinerary.  Another  option  may  be  to  alert the driver of current traffic conditions and give him alternate directions.

February 2008 

36 

UTh

InMoSion: Deployment Process Design 

6  System Simulation 
After  having  designed  the  system  in  terms  of  functional  properties  and  having  specified its operational parameters, it is now time to simulate its actual operation, using  tailor­made  software.  This  software  implements  the  very  same  system  core  algorithms  that will be used in the system’s actual operation.  A  simulation  model  synthesizes  the  characteristics  of  trip  requests  that  are  then  assigned  to  vehicles.  The  number  of  vehicles  is  increased  until  all  trips  are  served,  producing  the  tradeoff  between  vehicle  fleet  size  and  trips  carried.  Varying  design  parameters  (e.g.,  hours  of  service,  vehicle  size,  types  of  riders  served,  and  use  of  computerized  vehicle  scheduling)  will  assist  in  exploring  alternative  service  designs  in  support of planning decisions.  Having estimated demand for service and service rates (by means of analyzing the  survey  data),  which  vary  across  markets  (types  of  passengers  carried)  and  geographic  settings and are affected by vehicle size, operating strategies, and service quality, the goal  is to actually establish a relationship between the system’s operating parameters and the  resources  necessary  to  support  them.  There  is  also  day­to­day  variation  in  demand  for  service  and  in  operating  conditions  that  makes  the  problem  even  more  complex.  Furthermore,  the  demand  experienced  will  be  a  function  of  actual  service  quality,  and  thus  there  is  an  ongoing  equilibrium process  that  defines  the  required  fleet  size.  Stated  differently,  fleet  size  can  be  expected  to  evolve  as  service  is  delivered  and  experienced  and as demand responds to that service.  Inputs  required  for  the  conduction  of  the  simulation  may  probably  include  the  following: · Definition of the area to be served, with exact location of population centers and  distances between them · Definition of the types of riders (e.g., senior citizens, individuals whose mobility  is limited, or the general public); · Capacity of the DRT vehicle to be used; · Daily hours of service; · Service quality requirements and parameters (waiting time, maximum or average  trip duration, stand­alone or  in accordance with existing means of transport)

February 2008 

37 

UTh 

InMoSion: Deployment Process Design 

· Pricing policy · Daily trips to be carried. 

In general, there  is a strong positive correlation  between trips demanded and  fleet  size.  Other  factors  of  importance  are  service  area  size  and  trip  duration,  which  tend  to  increase  fleet  requirements  as  they  increase  (positive  correlation).  Two  more  important  factors  are  population  (trip)  density  and  vehicle  productivity  (related  to  many  factors  including types of riders carried), which tend to reduce the size of the fleet needed as they  increase (negatively correlated).  For  all  operators  of  demand­responsive  service,  the  tradeoff  between  quality  and  cost, when cost is largely driven by fleet size, represents a key decision variable. There is  no  optimal  fleet  size,  and  spending  more  resources  to  increase  the  fleet  size  will  either  serve a larger fraction of the market or serve the same market at a better service quality.  Another  important  goal  of  the  simulation  is  to  illustrate  the  possible  viability  or  profitability of the scheme. For a community/state run organization,  it is complicated to  establish  a  specific  point  of  optimum  operation,  for  it  is  not  clear  what  this  optimum  would  qualitatively  be,  and  therefore  quantifying  this  optimum  would  probably  entail  a  number of local (in conjunction to the simulation parameters) optimums.  Private­sector for­profit services use similar strategies for fleet sizing, and the same  factors are important. However, private firms tend to view vehicles as profit centers, and  thus they are less constrained by budgets and a desire to minimize fleet size. Furthermore,  they  tend  to  develop  very  reliable  estimates  of  vehicle  service  rates,  which  help  ensure  the accuracy of their fleet planning process.  In conclusion, the system simulation is performed in order to: · Identify critical operation points (service quality vs. price) · Identify number and type of vehicles · Identify initial running costs, possible income, profitability and viability · Examine the system’s performance under specific trip demands

February 2008 

38 

UTh

InMoSion: Deployment Process Design 

7  Pr oject Implementation 
7.1  Evaluation design 
Before the system is ready for operation, Indicators (data to be collected) linked to  scheme objectives must be defined. This will prove to be useful for the evaluation of the  system’s  pilot  and  actual  application,  both  of  which  will  follow  the  system  simulation.  Having  a  few  relevant  indicators  of  good  quality  is  certainly  better  than  attempting  to  quantify  every  possible  aspect  of  the  system’s  operation.  At  this  point  comes  the  appropriate  choice  of  methods  for  monitoring  and  evaluating  the  performance  of  the  service  and  the  time  schedule,  recurring  or  not.  One  must  decide  which  objectives/indicators need to be evaluated on a short term basis (e.g. monthly) and which  to evaluate on a long term basis (e.g. annually).  The  task  of  the  monitoring  and  evaluation  is  to  measure  the  performance  of  the  transport service, to gain knowledge about success and failure and to be able to adapt and  improve  the  service.  Monitoring  is  on­going  and  should  be  considered  as  part  of  the  implementation/operation  process.  Evaluation  looks  at  the  extent  to  which  objectives  have  been  met,  as  well  as  the  financial  performance  of  the  scheme.  It  is  important  to  compare the situation in the service area before and after the implementation of the new  public  transport  measures.  The  information  collected  after  the  implementation  of  the  service must therefore fit with the data collected in the initial evaluation. Indicators which  measure and describe impacts on the objectives of the transport scheme must be tested.  All groups of stakeholders should be taken into account during evaluation. Each of  the groups has to be questioned to find out how well their objectives were fulfilled by the  service. Qualitative or quantitative analysis can be used, depending on the indicators and  availability  of  data  and  information.  It  is  appropriate  to  perform  quantitative  analysis  frequently  (e.g.  monthly).  Quantitative  data  include  transport  data  such  as  number  of  trips,  vehicle  kilometers,  and  number  of  bookings.  Since  data  collection  for  qualitative  analyses  demands  a  greater  effort,  it  is  appropriate  to  carry  these  out  less  frequently.  Qualitative  data  include  satisfaction  levels  among  users,  operators  and  public  agencies,  and  can  be  obtained  through  questionnaires,  interviews,  and  focus  groups.  The  field  of  the  evaluation’s  implementation  is  the  pilot  application  (whose  necessity  will  be  established in the following section) and the actual system deployment

February 2008 

39 

UTh 

InMoSion: Deployment Process Design 

Data  collection  conducted  after  the  service  has  been  implemented  should  aim  to  assess  the  extent  to  which  the  service  is  meeting  the  requirements  identified  earlier,  to  explore  passenger  attitudes  and  opinions  regarding  the  service  provided  and  to  identify  changes in travel behavior. Data should be collected before and after implementation of  the new service in order to compare the two situations. The size and composition of the  survey  samples  must  be  as  consistent  as  possible  in  both  survey  periods.  It  is  essential  that a set of clear and realistic objectives are identified at the outset against which project  success will be assessed. If the implementation design is altered after the user survey, the  system  simulation  or  the  pilot  application,  than  the  evaluation  data  must  be  adjusted  accordingly. 

7.2  System Pilot Application and consequent Data Analysis 
After having simulated the system’s operation, and before  launching the scheme’s  formal  operation,  the  way  the  system  is  actually  formulated  and  the  simulation  projections must be confirmed. This can be accomplished by running a Pilot Application  of specific duration.  A pilot operating phase will provide the organizational  body with a  first approach  concerning the system’s behavior, along with the users’ acceptance towards the scheme.  Moreover, it will define if the pre­determined operation times are realistic or if they need  to be adjusted to actual demand.  Of utmost importance is the fact that the pilot application will identify specific user  needs,  improve  system  functionality  and  correct  unforeseen  design  or  operation  errors.  Also, issues concerning passenger pick­up and drop off at destination hubs may arise and  therefore be dealt with.  For all the above to be realized, the scheme’s organizational body must be ready to  accept increased customer feedback for the pilot application period. This means that the  operation center must be accordingly staffed (probably more than expected for every­day  actual operation) so as to be able to accept all inquiries, complaints and suggestions that  will  come  from  potential  or  actual  system  users.  Moreover,  user  feedback  must  be  collected from pick­up and drop­off locations, even on­board. This feedback is probably

February 2008 

40 

UTh 

InMoSion: Deployment Process Design 

the most valuable, for it reflects real system appreciation, not assumptions about how the  users will perceive the system’s operation.  The  principal  elements  to  be  analyzed  following  the  pilot  application  include  the  following: · Resources/Fleet size, drivers, reservation agents · Scheduling agent, types of vehicles · Number of calls attended, capacity of the system, training practices · Major operating costs · Frequency of service · Operational problems · Dispatching and scheduling method · Steps towards improvement 

7.3  Actual System implementation and evaluation 
The System should be implemented according to the action plan, the functions and  the  architecture  described  in  the  design  phase.  So,  the  final  implementation  should  include the following: ·  Setup the appropriate software and hardware ·  Setup all facilities concerning operators ·  Setup transportation means (vehicles contracts etch) ·  Start the service offering 

Data  for  monitoring  service  performance,  according  to  indicators  and  the  evaluation plan, should be collected continuously. The short term evaluation should also  be carried out.  An important task is to check if any new barriers occurred during operation, and try  to  overcome  them.  Timely  intervention  to  overcome  barriers  is  essential  in  order  to  ensure  uninterrupted  operations.  It  is  crucial  to  guarantee  a  continuation  of  the  service
February 2008 

41 

UTh 

InMoSion: Deployment Process Design 

(e.g. after initial subsidies have been spent). On the one hand, this may make it easier to  convince possible financiers and on the other hand, it is important to avoid the negative  effects on (potential) users if a service has to be suspended. Being flexible as possible and  ready to make changes if necessary (e.g. timetable, information) is always necessary.  In  the  same  context,  returning  to the  design  phase  to  redefine  the  scheme  or  alter  the service provided may also be necessary. If the service is not running according to its  principal characteristics, the scheme’s operational organization may need to trouble­shoot  or implement adaptations, even during the  first few days of the systems operation. That  means  that  poor  control  over  the  first  days  of  operation  may  have  a  severe  impact  and  impose an early termination.  On a long term basis, operation results need to be fed to the evaluation method, so  as  to  analyze  the  actual  impacts  of  the  service  and  consider  if  it  has  met  its  objectives.  Also, procedures need to be evaluated, again so as to identify the causes of barriers, their  context and the solutions required to overcome them.  Finally, the  evaluation results, along with experience gained  from operation,  must  be presented to the Stakeholders. Since the evaluation is made to improve, not close the  operation,  its  results  must  be  used  to  make  operational  improvements,  such  as  running  times and marketing material.

February 2008 

42 

UTh 

InMoSion: Deployment Process Design 

February 2008 

43 

UTh