Reference NBS

PUBLICATIONS ilHililin

NAT'L INST. OF STAND & TECH £

AlllDb D34EE7

NBSIR 85-3174

Paratransit Advanced Routing and

Scheduling System Documentation:

Functional Program and Data

Specifications

William G. Hall, Howard K. Hung and Robert E. Chapman

U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

National Engineering Laboratory

Center for Applied Mathematics

Gaithersburg, MD 20899

December 1985

Sponsored by:

U.S. Department of Transportation

Urban Mass Transportation Administration

of Technical Assistance

0 Second Street, SW

DC 20590

RESEARCH INFORMATION CENTER

NBSIR 85-3174

PARATRANSIT ADVANCED ROUTING AND

SCHEDULING SYSTEM DOCUMENTATION:

FUNCTIONAL PROGRAM AND DATA

SPECIFICATIONS

William G. Hall, Howard K. Hung and Robert E. Chapman

U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

National Engineering Laboratory

Center for Applied Mathematics

Gaithersburg, MD 20899

December 1985

Sponsored by:

U.S. Department of Transportation

Urban Mass Transportation Administration

Office of Technical Assistance

2100 Second Street, SW

Washington, DC 20590

U.S. DEPARTMENT OF COMMERCE, Malcolm Baldrige, Secretary

NATIONAL BUREAU OF STANDARDS. Ernest Ambler. Director
. V
PREFACE

This research was conducted under the sponsorship of the Paratransit

Integration Program (PTIP), Urban Mass Transportati on Administration (UMTA),

U.S. Department of Transportion, by the Center for Applied Mathematics,

National Engineering Laboratory, National Bureau of Standards.

Mr. Edward G. Neigut was the UMTA program manager for the project.

This report defines the functional program and data requirements for

automation of the routing,

paratransit vehicles. Its

software development. The

seri es.

scheduling and dispatching

content has been used as a

software will be described

functions for a fleet of

specification for

in other reports of this

i i i
ABSTRACT

This document specifies functional and data requirements governing automated

procedures for routing and scheduling dial-a-ride vehicles. It provides

overviews of existing methods and proposed methods, and summarizes

improvements and impacts. Requirements for functions, performance,

i nputs-outputs , data characteristics, and failure contingencies are discussed

fully. Three operating systems are specified. Finally, input and output data

are described, and data collection procedures are presented.

Keywords: Automated precedures; data requi rements ; dial-a-ride; functional

requirements; operating environment; routing and scheduling
Table of Contents

Page

Preface iii

Abstract iv

1. General Information 1 1.1 Summary 1 1.2 Environment 3

1.3 Level of Documentation 4

2. Overview 5 2.1 Background 5 2.2 Performance Objectives 6

2.3 Existing Methods and Procedures 8

2.3.1 Organizational and Personnel Responsibility 8

2.3.2 Equipment Available and Required 9

2.3.3 Volume and Frequency of Inputs and Outputs 9

2.3.4 Deficiencies and Limitations 9

2.3.5 Pertinent Cost Considerations 10

2.4 Proposed Methods and Procedures 11

2.4.1 Organizational and Personnel Responsibilities 11

2.4.2 Equipment Available and Required 11

2.4.3 Volume and Frequency of Inputs and Outputs 12

2.4.4 Deficiencies and Limitations 12

2.4.5 Pertinent Cost Considerations 13

2.5 Summary of Improvements 13

2.5.1 New Capabilities 14

2.5.2 Upgrading of Existing Capabilities 14

2.5.3 Elimination of Existing Deficiencies 15

2.5.4 Improved Timeliness 16

2.5.5 Elimination or Reduction of Existing Capabilities.... 16

2.6 Summary of Impacts 16

2.6.1 Equipment Impacts 16

2.6.2 Software Impacts 17

2.6.3 Organizational Impacts 17

2. 6.3.1 Functional Reorganization 17

2. 6. 3. 2 Staff Level Changes 17

2. 6. 3. 3 Upgrade/Downgrade of Staff Skills 18

2.6.4 Operational Impacts 18

2.6.4. 1 Staff and Operational Procedure 18

2. 6. 4. 2 Relations Between the Operating Center

and Its Users 19

2. 6.4. 3 Procedures of the Operating Center 19

2. 6. 4. 4 Data 20

2. 6.4. 5 Data Rentention and Retrieval 20

2. 6.4.6 Reporting Methods 21

2. 6.4. 7 System Failure Consequences and Recovery

Procedures 21

2. 6. 4. 8 Data Input Procedures 22

2. 6. 4. 9 Computer Processing Time Requirements

2.7 Cost Considerations

v
Page

3. Requirements 24

3.1 Functions 24

3.1.1 Type A System 24

3.1.2 Type B System 25

3.1.3 Type C System 25

3.2 Performance 26

3.2.1 Accuracy. 26

3.2.2 Validation 27

3.2.3 Timing 28

3. 2. 3.1 Response Time 28

3. 2. 3. 2 Data Transfer and Transmission Time 28

3. 2. 3. 3 Throughput Time 29

3.2.4 Flexibility 29

3.3 Inputs-Outputs 29

3.4 Data Characteristics 29

3.5 Failure Contingencies 30

3.5.1 Back-up 30

3.5.2 Fallback.... 30

3.5.3 Recovery and Restart 30

4. Operating Environment 32

4.1 Type A System 32

4.1.1 Equipment 32

4. 1.1.1 Processor and Size of Internal Storage..... 32

4. 1.1. 2 Storage, On-Line and Off-Line, Media, Form,

and Devices. 33

4.1.2 Support Software, Interfaces, Security, and

Privacy 33

4.2 Type B System 33

4.2.1 Equipment 33

4. 2. 1.1 Processor and Size of Internal Storage 33

4.2. 1.2 Storage, On-Line and Off-Line, Media, Form,

and Devices 34

4. 2. 1.3 Input-Output Devices 34

4.2. 1.4 Data Transmission Devices 35

4.2.2 Support Software, Interfaces, Security, and

Privacy 35

4.3 Type C System 35

5. Data Description.... 36

5.1

Static Data 36

5.1.1 Eligibility File 36

5.1.2 Subscription File 37

5.1.3 Address Directory Files..... 38

5. 1.3.1 Short Streets 38

5. 1.3. 2 Long Streets 39

5.1.4 Landmark Di rectory 39

5.1.5 Place Name Directory 40

vi
Page

5.1.6 Segment Speed File 40

5. 1.6.1 First Alternate Scheme 40

5. 1.6.2 Second Alternate Scheme 41

5.1.7 Minor Files 41

5. 1.7.1 Vehicle Files 41

5. 1.7. 2 Nominal Schedules 42

5. 1.7. 3 Miscellaneous 42

5.2 Dynamic Input Data 42

5.2.1 Dispatcher Inventory File 43

5.2.2 Dispatcher Assignment File 43

5.3 Dynamic Output Data 44

5.3.1 Vehicle Status Files 45

5.3.2 Check Point Files 45

5.3.3 Report Files 46

5.3.3. 1 Tickler File 46

5. 3. 3. 2 DAVE File 46

5.4 Internally Generated Data 47

5.5 Data Constraints 48

6. Data Collection 49

6.1 Requirements and Scope 49

6.1.1 Source of Input 49

6.1.2 Input Media 50

6.1.3 Recipients 50

6.1.4 Output Media 50

6.1.5 Critical Values 50

6.1.6 Scales of Measurement 50

6.1.7 Conversion Factors 51

6.1.8 Frequency of Updating 51

6.1.9 Frequency of Input 51

6.2 Input Responsibilities 52

6.3 Procedures 52

1. GENERAL INFORMATION

Paratransit services are defined as:

"... those forms of intraurban passenger transportation which are available to the public, and distinct from conventional transit

(scheduled bus and rail) and can operate over the highway and transit

system. 1,1

The paratransit systems for which the control systems described in this report

are relevant are those which have the following characteri sties:

1) Are demand responsive;

2) Use coordinated vehicle dispatching;

3) Offer shared-ride service;

4) Are available to the public;

5) Operate on street networks; and

6) Follow flexible rather than fixed routes and schedules.

The most common and familiar examples of systems having these characteri sties

are dial-a-bus and shared-ride taxi (or limousine) services. There are some

300 known systems 2 of this type currently in existence. Almost all of these

systems use manual routing, scheduling, and dispatching procedures.

Automation, if it exists at all, is typically confined to accounting type

functi ons.

1.1 SUMMARY

Studies have indicated that in a purely manual dial-a-ride or shared-ride taxi

system, good dispatchers can handle from seven to twelve vehicles effectively

1 Ki rby , R.F. , et al . , Paratransit: Neglected Options for Urban Mobility , Washington, DC: The Urban Institute, 1974.

Billheimer, J. W., et al ., Paratransit Handbook , Washington, DC: U.S.

Department of Transportation, UMTA-MA- 06-0054- 79-1, 1, 1978. This report,

nominally deals with how to implement a paratransit system. It contains a wealth of paratransit information including a taxonomy, details of a number

individual systems, and an excellent bibliography.

1
with the use of such aids as status boards, maps and pin boards. Beyond that

point, effective control becomes more difficult, assignments may not be as

efficient as possible, more vehicles may be used than are really required, and

qual ity-of-service may actually decrease. In the case of advanced reservation

or subscription services, the control problems are not quite as pronounced as

those of the demand-responsi ve services, but the manual development of

schedules and routes may not be the best possible, depending on the number of

vehicles, geography, times for pickup and delivery, etc., and it may be

difficult to insert late reservations in a tour. When different paratransit

services, or similar services provided by different operators, require

coordination, or centralization in order to promote efficiency, reduce costs,

and provide better service, then manual systems could become very

i neffi ci ent.

Paratransit services are implemented and are generally under the jurisdiction

of local and county governments, and are subject to higher level regulation,

guidance, funding support, etc., by state and federal governments. The types

of paratransit services and their degree of simplicity or complexity are

basically determined at the local level. Since the resources, skills, and

available monies are so variable at the local level throughout the country,

UMTA's paratransit integration program must be flexible, and ensure that its

R&D products can meaningfully satisfy the needs of the widest spectrum of

potential product users.

2
1.2 ENVIRONMENT

The paratransit software, when developed, should consist of a number of

standardized or "off-the-shelf" modules, each of which produces some output,

to another module or to an operator, to be used for totally automating the

process, or expediting the manual performance of dispatching, routing, and/or

scheduling of paratransit vehicles. Each of the modules is to be

cost-effective in the context of the total paratransit operation; that is, use

of one or more of the modules is to result in incremental benefits greater

than the incremental costs incurred, for a significant class of paratransit

operations. Since paratransit systems are extremely diverse in all of the

important attributes (size, goals, target population, etc.), it is not

necessary, nor even feasible, for each module to be appropriate for each

operation. The goal is to construct a set of modules of which some subset,

possibly augmented by "manual modules" is appropriate for a broad variety of

paratransit systems.

The concept of customizing a control system by combining off-the-shelf modules

and manual functions imposes some severe and unusual requi rements. The software modules must interface with each other, with manual operations, and with

non-control software; each module must be transparent to the user; each must

perform a "natural" function; a hierarchy of fail-back modes must be provided

and portability must be attained over hardware, system size, and the geography

and demography of the service area.

3
1.3 LEVEL OF DOCUMENTATION

To facilitate portability of programs, all will be written in ANSI FORTRAN

(ANSI X3.9-1978) 1

. Similarly, all flowcharts will conform to Federal

Information Processing Standards (FIPS) 24 2

. The documentation to support the

programs will conform to FIPS 38 3 and be detailed to the extent that it

constitutes a program specification should a user desire to rewrite the

program in any appropriate language.

L American National Standard Programming Language FORTRAN , New York: American

National Standards Institute, ANSI X3. 9-1978, 1978.

2 Flowchart Symbols and Their Usage in Information Processing , Washington, DC:

National Bureau of Standards, FIPS PUB 24, 1975.

3 Guidelines for Documentation of Computer Programs and Automated Data

Systems , Washington, DC: National Bureau of Standards, FIPS PUB 38, 1976.

4
2. OVERVIEW

2.1 BACKGROUND

The paratransit routing and scheduling software is to consist of modules

compatible with each other and with manual operations as well as other

automated procedures (in an input-output sense). The primary thrust is to

improve the control function of paratransit operations for a large fraction of

the existing and anticipated systems. Such improvement may be measured by the

change in cost or response time of the control system itself or in changes in

fleet utilization, service quality, profitability, or other appropriate

measures of operational efficiency. The consideration of candidate functions

for automation is not limited to those directly involved in routing,

scheduling, and dispatching. In fact, several non-control functions are very

attractive for automation in a cost-effective sense. Some specific examples

are:

(1) Patron eligibility inventory systems;

(2) Report generation for monitoring operations; and

(3) Agency billing systems.

The software is to be a mix of on-line and off-line operations. Off-line

functions include data base modifications, statistical calculations, billing

systems, report generating systems, global optimization systems, and patron

acquisition (patron-to-el igibi 1 ity file) systems. On-line functions generally

include only those functions directly involved with vehicle control, a patron

acquisition (call taker or eligibility file to dispatcher) system, report

generation of only those reports needed for real-time monitoring, fall Pack

procedures, or rebooting. Output files will be created for subsequent

off-line processing.

5
The on-line modules are further partitioned into two classes. The first is a

real-time command and control system concerned with fleet control and the

processing of patron information for patrons already assigned or currently

assignable. This subsystem is under control of the dispatcher. The second

on-line subsystem is real-time in a computer sense, but not in the command and

control sense; its primary function is patron acquisition from a mix of input

from a call-taker and associated data bases.

It is required that both on-line systems operate concurrently . This may be

accomplished via mul ti-programming or multi-processing within a single configuration or by dedicated, linked configurations.

Interfacing among the on-line subsystems, the off-line subsystem, external

systems, and manual operations will be in terms of input-output. Files and/or

subfiles must be amenable to transfer among subsystems; it is not necessary

that the subsystems be interactive in a real time sense.

2.2 PERFORMANCE OBJECTIVES

The goal is for the system to include an automated module for each function

for which such a module can be cost-effective in an important subset of paratransit operations. These modules must interface with each other and with external subsystems in such a way that the entire system is "friendly." Portability must be attained over as many paratransit systems as feasible. The

modules envisioned fall into three classes in terms of somewhat more specific

objectives. These correspond to the off-1 i ne , on-1 i ne , and real-time environments in which the modules will operate.

6
The off-1 i ne modules may operate in batch mode. The appropriate measure of

performance is throughput or some measure related to or derived from

throughput. The functions performed by these modules include file

construction and maintenance for operational files, calibration procedures for

data retained in operational files, and advanced scheduling and routing with

associated reports. The only interfaces with the other portions of the

operational system are via the operational files. There is no necessity for

an operational system interface; thus the off-line modules may be exercised on

a non-dedicated configuration.

The on-1 i ne modul es will be concerned primarily with patron acquisition whether for immediate assignment, deferred assignment, or recurring assignment; and

with procedures for assuring graceful degradation in case of system failures.

Orderly transition between automated and manual modules presents an especially

difficult problem. For these modules and for the real-time modules, response

time is the appropriate measure of performance.

The real-time modules will be exercised concurrently with the on-line modules.

They interact with the on-line modules via the sharing of some data. Their

primary functions are to monitor and modify vehicle itineraries and assign

patrons to vehicles. The modified itineraries, at the conclusion of the

monitoring procedure, constitute a history file.

For the most part, any global optimization will be performed within the offline subsystem. Real-time optimization will not be attempted except perhaps

some limited local optimization.

7
2.3 EXISTING METHODS AND PROCEDURES

Existing paratransit systems are incredibly diverse in all important

parameters -- objectives, target populations, service areas, size, and

equipment. This characteri sti c makes the modular approach mandatory; the

modules must accommodate considerable variation in the important parameters of

a prototype system. The target paratransit systems for automated aids are

expected to have 6 to 15 vehicles. The target population may be general,

restricted, or mixed by time-of-day or desired service level. Patronage may

be subscri pti ve, advanced request for service or immediate service. This

class of system includes almost all of those extant except :

(1) Those which are too small to justify even modest equipment costs;

(2) Those which are large enough to justify software specifically

tailored for local requi rements ; and

(3) Those which are integrated closely with mass transit operations.

The reasons for excepting the first two classes are self-evident; the third

class is excepted because of the excessive resources required (time, storage,

data base construction, and managerial, etc.) to store explicit networks

required for mass transit stops, schedules, and transfer points.

2.3.1 Organizational and Personnel Responsibility

A manual control system for the candidate paratransit operation would

typically include several call takers and several dispatchers; the exact

staffing being heavily dependent on service mode, target population, and

funding mechanisms. In most cases, operations personnel are charged with many

non-operational tasks; including generation of management reports, billing

activities, and eligibility determination.

8
2.3.2

Equipment Available and Required

Almost all control systems include voice radio for each vehicle and a base

station. A few allow digital transmission as well. Within the control

center, except for telephones, this includes:

(1) Manual file systems;

(2) Directories;

(3) Maps;

(4) A magnetic chart on which current and/or projected vehicles and/or

patrons are displayed; and

(5) A "tickler" board, essentially an incidence matrix of vehicles and

time intervals in which the entries represent assigned patrons.

2.3.3 Volume and Frequency of Inputs and Outputs

Input and output for the control system will vary considerably with the operational mode. Normally, there will be an input-output for each patron at

acquisition, at assignment to a vehicle, at pick-up, and at drop-off. Thus,

the total input-output is bounded by four times the number of patrons plus a

start and stop for each vehicle. Numerically, this means about 20 inputsoutputs per vehicle hour.

2.3.4 Deficiencies and Limitations

There is one major limitation and one major deficiency in the manual control

center. Both of these are intractable without a different approach to the

control system.

9
The major deficiency of even a small manual system is that any sort of optimization is simply too difficult to perform. This statement is true for both

minimization with respect to patron disutility, system disutility, or vehicles

required for a prescribed level of service; and maximization with respect to

vehicle utilization, revenues, or profitability. Any manual system, in practice, is limited to providing feasible solutions rather than optimal or even

good solutions. Operational consequences include the possibility of high

costs and/or poor service quality. At the management level, there is no way

to assess whether the control function is performed well or poorly relative to

the resources available.

The major limitation of manual systems is the fact that the complexity of the

dispatching problem is exponential with respect to the number of patrons.

This is a problem that has not been (and probably cannot be) resolved satisfactorily. Procedures which work well with up to n vehicles may become completely impractical for 2n vehicles. Attempts to avoid this blow-up result in

other difficulties; the most common of which is the transfer problem created by fleet partitions.

2.3.5 Pertinent Cost Consi derations

As with other important paratransit characteri sties , costing is so diverse as

to defy quantification. Cost per worker runs the gamut from free (volunteer)

to well-paid (organized transit workers). The entire operation can be characterized as a labor-intensive activity.

10
2.4 PROPOSED METHODS AND PROCEDURES

2.4.1 Organizational and Personnel Responsibilities

For the "typical" paratransit system, control system organization and

personnel are not expected to change a great deal. Most of the effects of the

automated system will, in fact, be more noticeable (see Section 2.5) in

non-control aspects of the system. Since the fallback control mode is

expected to be manual, substantial reduction in size of the control staff per

se is precluded unless management is willing to accept a di fferent type of

service or can augment the control staff when hardware is down. The

non-control staff may be reducible; most reporting requirements, for example,

may be met by fairly simple software with the control system audit trail as

i nput.

Personnel responsibilities for control staff will be changed only slightly.

Proficiency in present methods must be maintained to provide fallback. The

transparency and modularity requirements tend to make the functions and sequences of functions very much alike whether the system is manual or automated.

2.4.2 Equipment Available and Required

Except for the computer and associated peripheral devices, no change in existing equipment is envisioned. Digital transmission to/from vehicles could be

useful in some situations and its possible existence must be accommodated.

11
Several general sorts of configuration are appropriate for different types of

paratransit operation. For real-time control modules a dedicated configuration is required; for non-control, on-line modules, either a dedicated system

or a time-shared system is acceptable; for a subscription or advance notice

operation, the routing-scheduling modules may be run even in a batch mode.

Any combination of the preceding configurations, augmented by appropriate

input-output interfaces could be used.

2.4.3 Volume and Frequency of Inputs and Outputs

For the control system as such, input-output is expected to be equivalent to

that for a manual system. Volume will be slightly reduced since much inputoutput will be coded and formatted. There may be an increase in the frequency

of input-output due to the better monitoring capability. Provision for

interfacing with non-control functions or actually performing such functions

(e.g., explicit generation of transaction log, reporting, generation of

subscription trips, etc.) probably will cause some additional input-output

burden.

2.4.4 Deficiencies and Limitations

The only apparent deficiencies with the system as conceptualized are all related to down-time. First, although the automated system will speed up the

processing of control functions and result in more efficient utilization of

resources of the paratransit system, the requirement for a fail-back system

prevents any substantial staff reductions (at least for the control staff).

12
The other service problems arise in the transition to/from automated control

from/to manual control, and in the prescription of acceptable degraded modes

of operation. These are clearly problems of procedures external to the software; however, the procedures must be defined and formalized, and the software

must support them.

2.4.5 Pertinent Cost Considerations

The most important cost consideration to the operator is the procurement cost

of the hardware. There will be some cost incurred for training, but this is

expected to be in training current operating staff in different skill areas.

Software development costs are not borne by the operators; software maintenance costs should be small.

The target cost for a dedicated configuration is expected to be in the $ 25K to

$50K range. For the off-line modules (advance or subscription only), an

upper bound for costs can be determined by comparison with service bureau

charges.

2.5 SUMMARY OF IMPROVEMENTS

Although the proposed software is targeted specifically for control functions,

many of the improvements realizable will be more noticeable in non-control

areas. These, for the most part, will become attainable because the structure

and content of the data interfaces required for the control system are pertinent for other functions as well. The specific improvements expecte I or.?

therefore described in terms of those improvements due to the propose!

13
system and those peripheral to the actual control and scheduling systems

which will be realizable at small marginal cost.

2.5.1 New Capabilities

Since the control and scheduling system is a set of modules each of which is

designed to replace a "manual module," there will be no new capability in the

control and scheduling system per se. Several important new capabilities for

supporting functions will be attainable by utilization of the data base

(required for control functions) and the control audit trail (required for

fall-back). All operational data will be available in formatted form.

Detailed information will be useful for reports, trip tickets, billing,

mailing labels, etc., at a very moderate cost; summaries and reports for many

management functions not related to direct vehicle control will also be easy

to generate.

2.5.2 Upgrading of Existing Capabilities

Direct upgrading is expected in two major areas. First and most obvious is

that optimization methodologies are incorporated in some of the modules; in

some cases these are global optima; in others, local. Either sort of optimization is too complex and time-consuming to attempt in a manual system.

Any of several important characteri sties may be optimized: utilization of

equipment, quality of service, etc.

14
A second major area in which substantial improvement is expected is in the improved information available to manual elements of the control system. Information will be more complete and of better quality as well as more readily

accessi bl e.

Some of the modules will produce interim (CRT or hard copy) reports which will

constitute a nearly continuous monitoring of the paratransit operation. Reduction of these data will produce outputs useful for every aspect of paratransit operation from improving control data bases to system planning.

2.5.3 Elimination of Existing Deficiencies

The major deficiencies of manual systems can be dichotomized into deficiencies

within the control system itself and deficiencies in the interfaces with noncontrol elements.

Within the control system, optimization, at least to some extent will become

possible -- manual systems are almost totally preoccupied with feasibility.

The essential exponential nature of the routing/scheduling problem is not

eliminated, but the manageable size limit for paratransit systems is

increased. Dispatcher changes, whether by shift changes, break schedules,

or by hand-offs between dispatchers within the system, will be easier and

less disruptive to the service.

The interfaces among all elements of the operation will improve since all data

elements of interest will be explicit and accessible.

15
2.5.4 Improved Timeliness

The response time, as perceived by the patron, is expected to improve. Of

perhaps greater importance is the fact that the quality or value of the

response is "better" (in quality of service, resource utilization, or any

other measure of system performance) , and that by-products of the automated

procedure reduce the effort and time required for non-control operations

(billing, reporting, etc.).

2.5.5 Elimination or Reduction of Existing Capabilities

Existing capabilities will not be reduced by automation. This is because of

fall -back requirements, and the full-time coverage requirement. For some

systems, there may be staff reductions possible if:

(1) The mode of operation changes (e.g., demand--responsi ve to advanced

scheduling); or

(2) A degraded level of service is acceptable as fallback; or

(3) Short-term, short-notice support personnel are available as a

fall-back mode.

2.6 SUMMARY OF IMPACTS

This section will be limited to operations; automated modules are assumed to

replace their manual equivalents.

2.6.1 Equipment Impacts

Except for the computer hardware itself, no equipment impacts are envisioned.

The hardware to be used is expected to require no special site requirements

and little extra space.

16
2 . 6.2 Software Impacts

The software system is envisioned as essentially a "stand-alone" system. Interfaces with other application and support software will be by way of inputoutput. The software will be designed to operate under a "least-common

denominator (either a primitive or universal) operating system" likely to

be available for the target class of hardware.

2.6.3 Organizational Impacts

Organizational impacts are expected to be minimal except to the extent that

better knowledge and control may influence policy and/or objectives of paratransit management.

2.6.3. 1 Functional Reorganizati on

No major change is anticipated; in the long term, policy and objectives could

change as a result of more efficient operation.

2. 6. 3. 2 Staff L ev el Changes

The staff level will not increase; for certain situations, there may be a

decrease but such is not assured. Although the software will improve the

productivity in terms of patrons per hour for the system or vehicles per

controller, the threshold character!' Stic of staffing requirements may prevent

any control staff cutback. It is possible that improved vehicle utilization

may allow a reduction in the number of vehi cl es/dri vers required.

17
2. 6. 3. 3 Upgrade/Downgrade of Staff Skills

The skills required for an automated system are different from those required

for a manual system; the transition is more nearly lateral than upgrading or

downgradi ng.

For staff currently operating a manual system, new skills are necessary; these

are of a mechanical nature such as the use of input devices and interpretation

of CRT displays. Existing staff members can attain these skills fairly

quickly; no staff turnover is anticipated. The functions performed will be

the same; the tools for performing them will be improved.

For new employees, the skills required for operation of an automated system

are expected to be acquired more quickly and easily than those required for a

manual system. The only staff-skill problem anticipated is that of

maintaining manual skills when they are exercised i nf requently . The fall back

mode is expected to be manual operation.

2.6.4 Operational Impacts

2. 6. 4.1 Staff and Operational Procedures

The functions to be performed are nominally direct, one-to-one replacements

for functions now performed manually. Direct impact on staff and procedures

is therefore minimal; procedural changes are essentially at the mechanical

1 evel

18
In the long term, the existence and accessi bi 1 ity of better information may

lead to changed policies, goals, and objectives of paratransit operation. Although such changes can be expected, their nature cannot be predicted.

2. 6.4. 2 Relations Between the Operating Ce nter and Its Users

Two classes of user must be considered. For both classes, the automation will

not be perceived as a structural change. Users are interested in their input

to the system and in their output from the system. Whether the outputs are

generated from an automated system or the reading of tea leaves is irrelevant.

For both the patron user and sponsori ng/support i ng agency users, the input

side will remain as it is in a manual system. For both classes, information

outputs will be at least as good in terms of detail and frequency, and better

in terms of accuracy, reliability, and timeliness.

For the patron, the quality of service is expected to improve; for the paratransit agency, resource utilization will improve.

2. 6.4. 3 Procedures of the Operating Ce nter

For a dedicated equipment configuration, no existing computer services will be

impacted. For the time-sharing or batch environment, the patron acquisition,

file management, and routing/scheduling functions are expected to appear to be

exactly like other users. These functions present neither peculiar, esoteric,

nor especially stringent requirements.
2. 5.4.4 Data

Data are described more completely in Chapters 5 and 5. The major impact

perceived is that many data elements now implicit will be organized,

formatted, and stored explicitly. Many items (e.g., vehicle speeds, travel

times, expected schedules, geocodes, etc.) which now never appear in any sort

of physical file will be stored explicitly and amenable to retrieval and

systematic manipulation.

The sources for basic input data will continue to be primarily the patron and

the sponsoring agency. The only additional source foreseen is the output from

the system itself. Several files are prerequisite to an operational system:

(1) a patron eligibility Tile; and

(2) a geocoding file.

Neither of these files poses an undue start-up cost, and both will be amenable

to "friendly" updates, extensions, and refinements.

2. 6.4. 5 Data Re tention and Retrieval

Data retention and retrieval procedures will be quite conventional. The

static lot i Vise will not be modified during real-time operations. Dynamic

data will be maintained for only a short period of time; there is no necessity

for wholesale inserting of dynamic data into the static base. Interim data

will be of a throw-away type.

20
2. 6. 4. 6 Reporting Methods

Reporting will be both more detailed and more systematic than with a manual

system. These reports will include hard-copy and machine readable media;

recipients of the reports include other modules of the control system, control

system staff, non-control staff management, sponsoring agencies, and UMTA.

2. 6.4. 7 System Failure Consequences and Recovery Procedures

There appears to be no particular difficulty in controlling vehicles while the

system is down. There are several reasonable modes appropriate for different

types of paratransit:

(1) If the level of personnel has remained fixed, the control can

revert to the manual system;

(2) If the staff has been reduced, a degraded mode of operation must be

defined. These degraded modes are not part of the software; they

might include some or all of the following: (1) accepting no new

patrons, (2) retrograding to a check point system; (3) allowing only

subscription patrons; or (4) retrograding into a fixed schedule

system.

The transition from/to a manual to/from an automated system is extremely

difficult. The essential problem is that transition to/from manual from/to

automated implies that all data elements must exist in parallel in both a

machine-readabl e form and in a human-readable form. For the automated to

manual transition, a hierarchical checkpointing system in which the level',

vary from a single transaction to projected routes and schedules for all

vehicles should prove acceptable.

21
For the restart of the automated system, the problem is intrinsically more

difficult; any workable procedure is expected to include degraded operations

for an extended period of time. Section 3.5.3 discusses several alternative

approaches.

2. 6. 4. 8 Data Input Procedures

Data input for any specific configuration of modules will be conventional.

The sources may be hard-copy, oral, or machine-readable. Entry is expected to

be by keyboard, tape, disc, or anal og-to-di gital device. Data transfer among

modules will be conceptually input-output.

2. 6.4. 9 Computer Processing Time Requirements

For off-line modules, time is less important than cost; for other modules, the

automation is expected to result in improved timing.

2.7 COST CONSIDERATIONS

To a great extent, cost considerations are dominant in the system proposed.

In general terms, the goal is to accomplish as much as is reasonable with

acceptable total cost while retaining maximum portability. Features of the

proposed system which are almost totally dictated by cost considerations

i ncl ude:

(1) Modularity (automated and manual);

(2) Fall-back procedures;

(3) Implicit street networks;

22
(4) No additional communication requirement; and

(5) Accommodation of different hardware-software environments by

module.

Start-up costs for data base construction and training must be kept relatively

small. The modularity of automated functions, mapping one-to-one to presently

used manual functions, should be very valuable in this area. Operating staff

will require training only in new mechanical skills; the functions performed

are equivalent in an input-output sense to those currently performed manually.

In general, these characteristics which

center, impose additional but tolerable

acceptable trade-off since there is one

tional centers.

are very nice for the operational

burdens upon development; this is an

developer but a large number of opera

23
3. REQUIREMENTS

3.1 FUNCTIONS

In qualitative terms, the system is to include modules which replace manual

functions wherever such replacement will be cost-effective, whether such costeffectiveness is in terms of the control cost or overall paratransit operation

cost.

Different classes of the modules have different sorts of

the configuration and environment may be different. The

are described briefly in ascending order of initial cost

within each configuration are also described.

requirements; even

possible environments

Modules exercisable

3.1.1 Type A System

This system requires only a batch mode of operation; response times can be in

hours. The response time requirement can be met by a service bureau overnight

operati on.

For a completely off-line configuration, hereafter called Type A, no real-time

or direct control functions are possible. The major control function to be

performed is advanced routing and scheduling. Other modules related directly

to control functions will consist of procedures which support the optimization

algorithm in a pre-processi ng or post-processing sense. Major modules will be

patron acquisition (from a patron eligibility file), calculation of estimated

speeds and travel times, generation of reports for control staff, and

generation of trip itinerary reports for the vehicles. Updating of static and

dynamic files must also be performed; static files will, in general, be

24
modified by inputs not related to the control process; dynamic files by

monitoring of system performance relative to its predicted performance.

3.1.2 Type B System

This system requires interactive access; the response time must, for some

functions at least, be much shorter than that which is required for the Type A

system. This requirement can be met by a time-shared (with other users)

system.

A non-dedicated on-line system, hereafter called Type B, will include all of

the functions of a Type A system, but again will not contain any real-time

control functions. It will have additional modules for patron acquisition

(for patron eligibility and patron service request) via on-line data entry, a

"friendly" geocoding system, and a more comprehensive reporting capability.

The additional reporting capability is primarily the detailed patron request

augmented by geocodes, travel times, speeds, etc.; and hard-copy aids which

approximate the manual aids now in use (maps, tickler boards, etc.).

3.1.3 Type C System

This system requires, for some functions, very short response time. A

dedicated system or high priority use of a time-shared system is necessary.

A dedicated on-line or real-time system, a Type C system, will include all of

the Type B functions plus functions for real-time routing and scheduling. The

extensions are based on the real-time monitoring capability. Vehicle location

will be tracked by stop, patrons will be acquired for assignment as a function

25
of time, all transactions will be logged. If assignment is automated, a feasible or most nearly feasible (with respect to desired level of service) assignment will be sought. Any optimization will be completely local.

The real-time reports will look very much like the Type B reports except that

they represent observed status as well as projected status of the system.

They also include Type B reports whose element selection is based on user

supplied truth tables. These reports will be used for two purposes. The

first is as an alert to the operator; this is a warning as to occurrence

(actual or imminent) of some abnormal event - perhaps an unacceptably large

schedule slippage. The second use is as a basis for manual fall back; one

report is a snapshot of the current system state and will be produced

periodi cal ly.

Output from all system types must be amenable to reduction, summaries, etc.,

for non-control functions as well as control functions.

3.2 PERFORMANCE

Performance requirements will be different for Type A, B, and C systems or

more precisely, for the functions included in Type A only, Type B not in Type

A, and Type C not in Type B. The specific performance requirements will be

factored into those for each type of control system.

3.2.1 Accuracy

Accuracy requirements, in a computational sense, are not terribly stringent.

For locations, a quarter-mile error is acceptable. For travel times and

26
speeds, the objective is to obtain the best possible subject to data

limitations, and the fact that explicit representations of the street network

is to be avoided. The accuracy attained should be as good as is required; an

important characteristic is that the system be workable even with relatively

poor data. In an accounting context, or in the sense that no transaction be

lost or garbled, accuracy is extremely important.

Precision of computation is again not especially demanding. Probably as much

as 90 to 95 percent of the required calculations can be performed with fixed

point, sixteen bit arithmetic.

3.2.2 Validation

Static data bases will require some (off-line) validation procedures. These

are not foreseen as particularly demanding; they are expected to accompany

data base updating. Validation will consist mostly of "matching" and "ranging."

Dynamic and interim data bases, for the most part, will be generated via a

"prompting" mode of operation. Thus, within the automated modules, dynamic

and interim data will be as good as the static data base except for hardware

failure. Except for a completely automated system, every data element passed

from module to module will appear to operating personnel in readable form.

The routine application of "laugh" tests, although external to the automated

modules, should eliminate most errors which would result in grossly bad

routing or scheduling.

27
3.2.3 Timing

3. 2. 3.1 Response Time

Response time is not at all important for Type A functions; overnight or even

weekly turnaround should be adequate. Cost is much more important.

For Type B and Type C functions response time is important, but the

requirements are quite different. For Type B functions, which can be

time-shared, the interim or dynamic data generated will maintain their

usefulness in spite of poor response time except in a request for immediate

service. Good response time will not improve fleet performance; it will

improve the efficiency of personnel and provide convenience to the patron.

For Type C functions, the interim or dynamic data will lessen in quality, accuracy, and relevance with the passage of time after initiation of computation. Thus, poor response time will degrade the entire paratransit operation.

3. 2. 3. 2 Data Transfer and Transmission Time

For Type A systems, there is essentially no time constraint. For Type B and

Type C systems, the most stringent requirement is for modul e-to-modul

transfer of information where either or both modules may be automated.

Generally, there will be less data transmission i ntermodularly than

i ntramodul arly. The target class of hardware should be quite acceptable.

28
3. 2. 3.

Throughput Time

There is basically no throughput requirement. For Type A systems, cost is

much more important; while for Types B and C, which are real-time, throughput

measures are totally irrelevant; response time is the appropriate criterion.

3.2.4 Flexibility

Flexibility of the system, or the amenability of the system to change as requirements change, is assumed by the very concept of the modular approach. A

change in requirements over time is no different from separate requirements

for different systems.

3.3 INPUTS-OUTPUTS

For this application, intermodular data transfer is perceived as either additional input, output, or as very precisely defined interfaces. These

inter-modular i nputs-outputs will be described in detail in the appropriate

System/Subsystem Specification. It is necessary to consider these interfaces

as i nputs-outputs because of the automated-manual nature of the modules.

Interfaces between modules are interim data bases if both modules are

automated but must be considered as i nputs-outputs if the one module is

automated and the other manual. Several media and various formats will be

accommodated in terms of i nputs-outputs for the hybrid system.

3.4 DATA CHARACTERISTICS

Data characteristics are described in Chapters 5 and 6.

29
3.5 FAILURE CONTINGENCIES

For Type A functions, no unusual procedures are required. The remainder of

this section will be concerned with Type B and Type C functions.

3.5.1 Back-Up

Within the target configurations, there will be little or no hardware

redundancy. Extra tape drives, disc drives, CRT's, etc., may well be

available and usable for back-up; files for back-up will be via a grandfather

file technique. However, any hardware redundancy is expected to consist of

substitution of functionally equivalent systems or subsystems. It is not

required that the system be reconfi gurable if components go down. No degraded

modes of operation are required.

3.5.2 Fall-back

The fall-back procedures are essenti al ly the procedures now being used. This

is a major reason for the transparency requirements. Fail-back to manual

operations will inevitably result in a degraded efficiency or quality of

service provided. The software will generate reports at checkpoints

periodically and log subsequent transaction information. There will be a

hierarchy of such checkpoints; these are to provide a bridge between automated

and manual operation.

3.5.3 Recovery and Restart

This is the most difficult requirement of the entire system. There is no obvious way to recover and restart that is even close to being sati sfactory

30
The essential problem is that rather large masses of data must be entered very

quickly; much of this exists only in an implicit and unformatted form in manual operation.

Several alternatives are to be explored; these include but are not limited to:

(1) Phased restart This strategy would involve bringing modules "up" in

a predetermined sequence (i.e., a scheme whereby the automated

modules restart in a prescribed order).

(2) Cycled restart This strategy involves a transition to automated

operation by vehicle or some subfleet of vehicles.

(3) Resurrected restart This strategy updates, from the last checkpoint

before failure, by entering each subsequent transaction accomplished

manually. This could be done via parallel recording of transactions

on some batch loadable medium.

(4) Generalized representation This strategy would use generalized or

summary information to synthesize a current status representative of

(in the most important characteri sties) the true status.

31
4. OPERATING ENVIRONMENT

The environment can vary greatly depending mostly on the control system type.

Characteristics and objectives of the paratransit system also have a strong

influence, but much of this influence will be considered in the selection of

4.1 system type.

TYPE A SYSTEM

4.1.1 Equipment

No new ADP equipment is required for the control site per se. The entire system requires only a service bureau type of operation. Requirements are thus

access to rather than control of the ADP resources described.

4. 1.1.1 Processor and Size of Internal Storage

The prototype routing scheduling procedure is written in FORTRAN 77, and is

executable on the UNIVAC 1100 series computer. For an 8-vehicle, 85-patron

system, it will run in 65K of core in about 5 minutes. Since this program is

a prototype with known inefficiencies with respect to both storage and time,

the numbers cited can be considered an upper bound on processor resources.

Nearly all of the calculations, for example, can be performed with 16-bit,

fixed point, single precision arithmetic. The advanced routing/scheduling

modules are expected to be the most demanding with respect to computation and

internal storage. Other modules are expected to be much less computational ly

i ntensi ve.

32
4.

1.1.2

Storage, On-Line and Off-Line, Media, Form, and Devices

Good quality hard copy reports should be provided. Except for these, the

storage, media, and devices are the responsibility of the service bureau.

4.1.2

Support Software, Interfaces, Security, and Privacy

No particular problems are foreseen in these areas.

4.2

TYPE B SYSTEM

4.2.1 Equipment

The Type B system is on-line but may or may not utilize a dedicated

confi guration.

4. 2. 1.1 Processor and Size of Internal Storage

Major data bases will be of the unit-record type based on patron (eligibility,

dispatcher inventory and assignment status), based on piecewise linear street

segments, based on place names, and based on landmarks. Each of these static

data records will be of the order of 100 characters. Since all static data

are potentially required in the patron acquisition process, all must be

accessible within a few seconds. If the system is time-shared, almost any

commercial time-sharing system is internally as powerful as necessary in both

time and storage.

33
If the system is micro-based, the targeted price class of hardware should be

more than adequate if the operational mode is compilation rather than

i nterpretati on.

4. 2. 1.2 Storage, On-Line and Off-Line, Media, Form, and Devices

Whether time-shared or dedicated, there is a requirement for a substantial online storage capability. Although supporting software for updating the data

bases is to be provided, updating can be relatively slow; it is not necessarily done in real time. Internally generated data will be orders of magnitude

less in terms of size but will have about the same response time requirement.

Conventional hard disk characteristics are more than adequate for both

functi ons.

Off-line storage, except for back-up of on-line, poses no demanding volume or

response time requi rements ; it must exist but can be relatively slow. It may

be floppy disk and/or cassette.

4. 2. 1.3 Input-Output Devices

Whether dedicated or time-shared, input-output requirements will be quite

similar. The patron acquisition procedure is conceived as operating in a

prompting mode; CRT terminal devices will be the busiest input-output

components. The output (CRT) side is several orders of magnitude greater than

input (keyboard). A moderate speed hard copy device is also required; this

could be a line printer or CRT copy device.

34
4. 2. 1.4 Data Transmission Devices

No transmission is involved except between the terminal and the CPU.

4.2.2 Support Software, Interfaces, Security, and Privacy

With a time-shared system, the applications program must conform to the computer center requirements. Applications must be based on a least-commondenominator philosophy insofar as is feasible.

For a dedicated system, at least a primitive operating system is expected.

File handling must be rather good; it may be attained by raw hardware

capability, operating system, or operating system augmenting application

programmi ng.

Interfaces, privacy, and security do not appear to pose any limiting requirements.

4.3 TYPE C SYSTEM

This has much the same appearance as a dedicated Type B system. The

additional processing is primarily of the transaction type. The configuration

must support an additional terminal for each dispatcher, be capable of

producing interim reports, and performing patron insertion into vehicle

itineraries; the last function is to be at least feasible; and at most,

locally optimized.

35
5. DATA DESCRIPTION

The data are described in this section as being in files. The term "files" in

this context implies that the software has access to the content indicated.

There is no intent to represent every data element in exactly the form in

which it will appear physically in terms of formats, indices, pointers, etc.,

nor is there any implication of file structure in the computer science sense.

5.1 STATIC DATA

Data are considered static if they are not subject to modification by the

processes of patron assignment to a vehicle or vehicle control. Static data

are used in a read only mode insofar as the control process is concerned.

Updating is assumed to be periodic and does not have to be performed online.

For most of the static files there will be an internally generated parallel

file containing the entities captured, corrected, or marked for purging since

the last periodic update. The form of data is indicated by element with T for

free form text or F for formatted.

5.1.1 El igibi lity File

This file is required for paratransit systems in which patrons' eligibility

must be formally established, and for systems in which some part of the cost

is borne by some other agency. The file is optional in other cases; it would

be useful if there are a large fraction of habitual users. The file is

accessed by the receiver of the request for service.

36
The file entity is the patron; data elements are:

(1) Name (T);

(2) Identification (F);

(3) Home Address (T);

(4) Geocode (F);

(5) Telephone (F);

(6) Address Prefix (F and T);

(7) Sponsoring Agency (T);

(8) Billable Agency (F);

(9) Starting Date (F);

(10) Ending Date (F);

(11) Destination (F and T);

(12) Destination Geocode (F);

(13) Class (F and T).

5.1.2 Subscription File

This file is accessible to the dispatcher on demand, and to the software as a

function of real time. Dependent upon the paratransit system, it may replace

or augment the eligibility file.

The file entity is the patron; the data elements are:

(1) Name (T);

(2) Identification (F);

(3) Home Address (T);

(4) Geocode (F);

(5) Telephone (F);

(6) Address Prefix (F and T);

37
(7) Sponsoring Agency/Authorization (T);

(8) Bi liable Agency (F )

(9) Starting Date (F);

(10) Ending Date (F);

(11) Destination (F and T);

(12) Destination Geocode (F);

(13) Class (F);

(14) Frequency Code (F )

(15) Pick-up Time/Code (F); and

(16) Return Time/Code (F);

5.1.3 Address Di rectory Files

Street addresses are used as input to produce geocodes in two slightly

different ways. For either case, the street address may have a prefix

denoting community within transit area. Short streets will be considered as

points; a short street is one which has a total length of a half mile or

1 ess.

5. 1.3.1 Short Streets

The file entity is the street; the data elements are:

(1) Prefix (optional) (F);

(2) Street Name (T); and

(3) Geocode (F).

38
5. 1.3. 2 Long Streets

Long street addresses are geocoded by linear interpolation of a piecewise

linear segment representation of the street. The entity is the line segment;

the elements are:

(1) Prefix (F),

(2) Lowest Number (F) (includes modifier such as N, S, etc.);

(3) Geocode for Number (F); and

(4) Street Name (T) (First Only).

5.1.4 Landmark Directory

For a paratransit system which is many-few, either de facto or by policy, a

geocoding shortcut is provided. For commonly used end points a special short

code, probably three characters, is used for geocoding. These short codes

will be selected by the user; they could be mnemonic, acronymns, or structured

in some consistent way (H for hospital, M for shopping mall, etc.). Checkpoints could be used interchangeably with landmarks or could be in a similar

parallel file. Use of this scheme avoids the prompting mode required for the

other schemes and minimizes I/O. The cost is that the operator must Tiemorize

the landmark codes. The file entities are landmarks (checkpoints); the data

elements are:

(1) Code (F);

(2) Geocode (F); and

(3) Name (T).

39
5.1.5 Place Name Directory

This directory accommodates places which are not commonly located by street

address but are not used frequently enough to be considered landmarks. Places

such as schools, stores, minor shopping centers, etc., are included.

Reference is by place name and execution is in the prompting mode. The file

entities are the places; the data elements are:

(1) Place name (T);

(2) Geocode (F); and

(3) Street Address (F).

5.1.6 Segment Speed File

This file is used to calculate an estimated segment speed. These speeds will

be used in making "good" patron assignments to vehicles. This file could be

replaced and/or augmented for some paratransit operations. As examples, a

checkpoint system might store point-to-point travel times explicitly; the

transit area might be sufficiently homogeneous with respect to attainable

speed that travel times can be calculated to required accuracy as a function

of euclidean or rectilinear distance.

Two slightly different files seem equally appropriate at this time. In each

case the entity is a zone.

5. 1.6.1 First Alternate Scheme

This method minimizes on-line computation time but requires more storage and

more complex updating procedures. The entity is the zone; the data elements

are:

40
(1) Origin Geocode (F);

(2) First Destination Geocode (F);

(3) 0-D Attainable Speed (F);

(4,5) As (2) and (3) for Second Destination Zone; and

(2n,2n+l) As (2) and (3) for n th Destination Zone.

The zone is simply a rectangular area defined by its maximum and minimum

coordi nates.

5. 1.6.2 Second Alternate Scheme

This scheme has the advantages of minimizing storage requirements and updating

complexity, and provides for alternative point-to-point paths; these

characteristics are attained at the expense of more on-line computation. The

file entity is the zone; the data elements are:

(1) Geocode (F) (minimum coordinates); and

(2) Attainable Speed Within Zone (F).

5.1.7 Mi nor Files

There are several other files which may or may not be required for particular

paratransit systems.

5. 1.7.1 Vehicl e Files

One or more files may exist with vehicles as entities. These could contain

control data as capacity, special equipment such as lifts, etc. They coul i

also contain information which is primarily for noncontrol operations but V

41
marginal utility to control such as preventive maintenance schedules; these

data could be used to explicitly accommodate noncontrol constraints into the

control process.

5. 1.7.2 Nominal Schedules

For either subscription service, or service with many recurring trips, it may

prove advantageous to use a previously exercised itinerary as a prototype;

this can be modified initially by deleting non-holdover patrons. Patrons may

then be inserted to an existing itinerary using procedures which are certainly

less complex and probably more nearly optimal per computation dollar.

5. 1.7.3 Mi seel 1 aneous

There will be a number of miscellaneous data elements whose parent entities

are not clearly defined. These data primarily relate to noncontrol activities

but may impose constraints upon the control process. Some examples are:

(1) Vehicle Availability by Time;

(2) Personnel Resources by Time; and

(3) Required Locations for Fueling, Lunch Breaks, etc.

5.2 DYNAMIC INPUT DATA

The basic concept of system operation is to minimize the data actually input.

Instead the dynamic data is, insofar as is practicable, to be selected from

static data. Since the software is to operate in a prompting mode, the intent

is to minimize the number of key strokes required to select from and augment

as necessary static data to construct dynamic data.

42
Aside from the initialization or start-up procedures, which may require explicit input, the data entered will be for patron acquisition, for patron assignment, or for system monitoring. The actual inputs are mostly keys to initiate

procedures or parameters for use by the procedures generated.

5.2.1 Dispatcher Inventory File

Entities in this file are the patrons to be served within some specified time

horizon. The file entries are constructed by an individual request for

service or by clock time controlled generation from the subscription file.

The elements are:

(1) Name of Patron (T);

(2) Origin Prefix (F);

(3) Origin Address (T);

(4) Origin Geocode (F);

(5) Destination Address (T);

(6) Destination Geocode (T);

(7) Class (F);

(8) Time/Code (F); and

(9) Minimum Travel Time (F).

5.2.2 Dispatcher Assignment File

This is very much like the Dispatcher Inventory File except that its entities

represent patrons who either have been assigned or must be assigned to a vehicle within a fairly short time interval. It is accessible only to the dispatchers. The data elements are:

43
(1) Name of Patron (T);

(2) Origin Prefix (F);

(3) Origin Address (T);

(4) Origin Geocode (F);

(5) Destination Address (T);

(6) Destination Geocode (F);

(7) Class (F);

(8) Time/Code (F);

(9) Minimum Travel Time (F);

(10) Vehicle Assignment (F);

(11) Expected Pick-up Time (F);

(12) Actual Pick-up Time (F); and

(13) Expected Destination Time (F).

5.3 DYNAMIC OUTPUT DATA

Dynamic output data are defined to be those data which must be accessible

during some part of an operational cycle but which have no residual value.

The intrinsic value of the entire file becomes zero at the end of the operational cycle; individual entities or elements may become superfluous as a

function of time or occurrence of some event during the operational cycle.

These files may be considered as interim files.

44
5.3.1 Vehicle Status Files

For ease of exposition, a separate file is assumed for each vehicle. This

file contains all vehicle information relevant to the dispatcher. The

entities are all stops related to on board patrons, assigned patrons, or

patrons pre-schedul ed for a dispatching time horizon. It is used to generate

interim reports for check pointing, monitoring, or aiding in manual

assignment. The data elements are:

(1) Stop Time (F);

(2) Patron Index (F);

(3) Geocode (F);

(4) Stop Purpose (F);

(5) Patron Disutility (F); and

(6-n) Repeat of (1) - (5) for all other pertinent stops.

5.3.2 Check Point Files

The precise information required for a check point or restart is not yet

fixed. Several alternative procedures, discussed in Section 3.5,

must be explored. These files are therefore discussed qualitatively in terms

of the functions these data must support. Some set of hard copy files must be

created periodically; these must expedite both the transition to manual

operation and restart procedures.

To the extent that there is functional redundancy present within the configuration, alternate medium backups should be provided. The backup is to be limited to a more-or-less direct substitution; no reconfiguration is expected.

45
The checkpoint procedure is to be hierarchical in the sense that it should

provide a good global snapshot of the system at checkpoints with interim

information at one or more echelons between checkpoints. These interim

outputs should provide reasonable, with respect to time and complexity, cross

walks to current system status for the transition to manual operation.

5.3.3 Report Files

These reports are those used within the control process. They may be hardcopy or CRT and may be digital or graphic. Whether or not the bases for the

reports exist as distinct files or the reports generated from the static dynamic, or internally generated files directly, is an open question. Two sorts

of reports, both analagous to present manual aids are envisioned; other sorts

are, of course, not precluded. For each type described, certain Boolean functions are to be provided in the report selection keys. Reports, in particular, are to be produced by time interval, by vehicle, by patron class, etc.,

and by Booleans of the same.

5. 3. 3.1 Tickler File

This is the analog of the manual tickler board. In essence, this is a matrix

whose rows and columns represent vehicles and time intervals and whose

elements represent characteri sties of interest.

5. 3.3.2 DAVE File

This is the analog of the DAVE board. The report is a map annotated with vehicle and/or patron characteristics of interest. If graphical capability (not

46
part of the proposed software for development) is available, it will be used.

Otherwise, the analog information is to be approximated digitally.

5.4 INTERNALLY GENERATED DATA

These data are those which have permanent or at least long-term value. They

supply a history of the system operation which is directly required for modification and calibration of the static data. Additionally, they are useful

for studying both the control procedures and management of the paratransit

system as a whole. They also provide input for noncontrol software for satisfying reporting, accounting, and billing requi rements. The file entity is

the patron; the elements are:

(1) Name (T);

(2) Identification (F);

(3) Address (T);

(4) Geocode (F);

(5) Telephone (F);

(6) Address Prefix (F and T);

(7) Sponsoring Agency (F and T);

(3) Billable Agency (F and T);

(9)

Authorization Starting Date (F);

(10) Authorization Termination Date (F);

(11) Destination (F and T);

(12) Destination Geocode (F);

(13) Class (F);

(14) Date of Service (F);

47
(15) Times (F):

(a) Request Received;

(b) Requested Service;

(c) Assignment;

(d) Estimated Pickup;

(e) Estimated Dropoff;

(f) Minimum Travel Time;

(g) Actual Pickup;

(h) Actual Dropoff;

(i) Disutility;

(j) Cancellation; and

(k) No-Show.

(16) Vehicle

5.5 DATA CONSTRAINTS

There are no unusual data constraints except that the volume of static data

required is rather large and may be only weakly related to the number of

control transactions. The portability requirement implicitly precludes

substantial ly different file structure for different systems. Accessibility

requirements appear to be unrelated to system size except as response time is

affected.

48
6. DATA COLLECTION

6.1 REQUIREMENTS AND SCOPE

Only the structure of the data bases will be provided by the developers; there

will be no formal data collection activity. However, certain default data

bases may be provided for use prior to local data collection and/or calibrations. For example, a travel speed table may be constructed by the developer

using uniform travel speeds; this is usable for training and initial operation

but should be updated fairly quickly.

User data collection similarly can be phased in several different ways.

Either certain data bases (landmark or street address as examples) could be

defined, or data bases could be synthesized (for the address file, each street

could be considered a single straight line segment).

Incomplete or inaccurate data will obviously affect the performance of the

system. The design concept will accommodate local errors without catastrophic

failure. The quality of the routing/scheduling procedure is intended to be as

good as the input.

6.1.1 Source of Input

All data used for routing/scheduling are expected to be entered from the control center of the paratransit agency. Static data bases may be entered or

modified by control staff or some other group.

49
6.1.2

Input Media

Input media will be those conventionally used for batch processing (cards and

magnetic tape) and CRT-keyboard terminals. For the development, all input is

expected to be digital.

6.1.3 Recipients

For the control system itself, all recipients of output will be within the

control group. The only exception foreseen is if some other group is operationally responsible for updating data bases and/or reduction of operational

data to provide inputs for updating. Of course, output data may provide

inputs to other software which produces reports targeted for other users.

6.1.4 Output Media

For internal (routing/scheduling) the output media expected are digital CRT

and medium speed hard copy. Graphic (CRT and/or hard copy) may be used.

6.1.5 Critical Values

No particular values for any data element appear to be critical.

6.1.6 Scales of Measurement

The scales and measures will be those used by or familiar to manual operators.

Some variables such as penalties or disutilities may be new, but their units

will be familiar and the concept will be transparent.

50
6.1.7

Conversion Factors

Analog to digital devices, if used, should not pose any problems; accuracy and

precision of conventional procedures is more than adequate. The units for input and output will be identical; those used internally are immaterial to the

user.

6.1.8 Frequency of Updating

The desirable frequency of updating of static data is more dependent upon the

volume of changes than upon a fixed time interval. The frequency of updating

would be expected to differ by user with the primary determinant being the

change in patrons. For calibration updates (dwell times, travel times, etc.),

there should be enough observed data to produce improved parameter

estimates.

At most, updates will be performed daily; a more likely update interval will

be weekly. After some period of successful operations, it is feasible that

calibration updating will not be required at all. Whatever the required frequency, it does not have a large impact upon response time requi rements

6.1.9 Frequency of Input

Dynamic input into the system is a direct function of the patronage except for

subscription or repeat patrons who may be retrieved from the static data

bases. At worst, the dynamic input is one entry/patron trip (actually a little less since for round trips, most if not all of the return trip information

can be generated with the original trip).

51
Input-output internal to the control system, modul e-to-modul e transfers, will

be of much higher volume. The volume is controllable in normal operation by

good file design; a mix of alternating manual and automated procedures is the

worst case since input-output also implies transformation. Back-up and

restart procedures are expected to be particularly difficult.

6.2 INPUT RESPONSIBILITIES

Except for default or synthesized data bases to be supplied by the developer,

all input data is the responsibility of the user.

6.3 PROCEDURES

For software development, the data structures are far more critical than data

element values. A basic premise in development philosophy is that all parts

of the system must be amenable to incremental and evolutionary changes at each

operational site. Primarily, this is to insure portability and transparency

but a concomitant impact is that data gathering procedures may be ad hoc and

differ by operational site.

52
NBS-114A (REV. 2*90

)

U.S. DEPT. OF COMM.

BIBLIOGRAPHIC DATA

SHEET (See instructions)

1. PUBLICATION OR

REPORT NO.

NBSIR 85-3174

2. Performing Organ. Report No. 3. Publication Date

DECEMBER 1985

4. TITLE AND SUBTITLE

Paratransit Advanced Routing and Scheduling System Documentation: Functional

Program and Data Specifications

5. AUTHOR(S)

William G. Hall. Howard K. Hung and Roherf. F. Chapman

6. PERFORMING ORGANIZATION (If joint or other than NBS. see instructions)

NATIONAL BUREAU OF STANDARDS

DEPARTMENT OF COMMERCE

WASHINGTON, D.C. 20234

7. Contract/Grant No.

8 . Type of Report & Period Covered

9.

SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (Street. City, State. ZIP)

Department of Transportation/Urban Mass Transit Authority

Program Operation and Support Division

2100 Second Street S.W.

Washington, D.C. 20590

10.

SUPPLEMENTARY NOTES

| | Document describes a computer program; SF-185, FlPS Software Summary, is attached.

11.

ABSTRACT (A 200-word or less factual summary of most significant information. If document includes a significant

bibliography or literature survey, mention it here)

This document specifies functional and data requirements governing automated

procedures for routing and scheduling dial-a-ride vehicles. It provides overviews

of existing methods and proposed methods, and summarizes improvements and impacts.

Requirements for functions, performance, inputs -outputs , data characteristics, and

failure contingencies are discussed fully. Three operating systems are specified.

Finally, input and output data are described, and data collection procedures are presented.

12. KEY WORDS (Six to twelve entries; alphabetical order; capitalize only proper names; and separate key wore, sv Automated procedures; data requirements; dial-a-ride; functional requirements;

operating environment; routing and scheduling

13. AVAILABILITY 14. NO. OP

PRINTEO PACES

Unlimited

| | For Official Distribution. Do Not Release to NTIS 60

| | Order From Superintendent of Documents, U.S. Government Printing Office, Washington, O.C. 20402. 15. Pf.ce

|~^~| Order From National Technical Information Service (NTIS), Springfield, VA. 22161 $11.95
f. . i : 1 A..V 1 1 i :i> '

d