autonomous dial-a-ride transit introductory overview - Science Direct

Transpn. Res.-C, Vol. 3, No. 5, pp. 261-275, 1995 Copyright 0 1995 Elsevicr Science Ltd Printed in Great Britain. All rights reserved 0%8-090X/95 39.50 + 0.00

Pergamon

(b9so9ox(953ooo10-0

AUTONOMOUS DIAL-A-RIDE TRANSIT INTRODUCTORY OVERVIEW

The Volpe National

Transportation

ROBERT

B. DIAL

Systems Center,

Kendall

Square,

Cambridge,

MA 02141, U.S.A.

(Received 20 March 1995; in revisedform 18 August 1995) Abstract-This paper introduces a modernized version of many-to-few dial-a-ride called autonomous dial-a-ride transit (ADART), which employs fully-automated order-entry and routing-andscheduling systems that reside exclusively on board the vehicle. Here, “fully automated” means

that under normal operation, the customer is the only human involved in the entire process of requesting a ride, assigning trips, scheduling arrivals and routing the vehicle. There are no telephone operators to receive calls, nor any central dispatchers to assign trips to vehicles, nor any human planning a route. The vehicles’ computers assign trip demands and plan routes optimally among themselves, and the drivers’ only job is to obey instructions from their vehicle’s computer. Consequently, an ADART vehicle fleet covers a large service area without any centralized supervision. In effect, the vehicles behave like a swarm of ants accomplishing their chore without anyone in charge. I. INTRODUCTION

This paper proposes a modern approach to many-to-few dial-a-ride transit (DART) operation, which uses more recent off-the-shelf consumer and computer technology [for DART introduction, see Wilson and Roos (1971)]. Called autonomous dial-a-ride transit (ADART) to distinguish it from conventional systems, this approach promises improved service and reduced costs. Furthermore, ADART’s superiority over conventional dial-aride prevails whatever the size of the system and becomes more significant as the system gets larger. 1.1 Ideas behind ADART The ideas behind ADART are simple. They have four components: marketing, operational, accounting and technical. The marketing component targets recurring trips, which account for over 50% of urban travel. These include trips to attraction centers for work, shopping and personal purposes. ADART targets these recurring trips because they form a lucrative market. They are serviceable with many-to-few operations and provide “repeat business,” the life blood of an enterprise profiting on high volume. The operational component eliminates communication with telephone operators to arrange travel, by providing a customer interface similar to automatic teller machines (ATM) and banking by phone. ADART passengers never converse with telephone operators, only with computers on board the vehicle. The accounting component obviates traditional fare collection, by using bank credit cards and electronic funds transfer for processing accounts receivable. The technical component replaces the centralized dispatching function with a fully automated distributed system, which: l

l

assigns trips to vehicles, devises itineraries, and plans routes without human intervention; and has its dispatching hardware and software on board the vehicle.

Each vehicle’s computer communicates with its vehicle’s driver and other computers. Having no central control, an ADART fleet behaves like a swarm of ants doing their 261

262

Robert B. Dial

work with no one in charge. This is not to suggest that an ADART operation lacks central management. Vehicle and data maintenance, technical trouble shooting, service quality control, pricing, hiring, firing, automatic call distribution, billing and accounting are a few examples of functions best served by ADART’s central management. However, an ADART operation has negligible centralized intervention-mechanical or humanbetween the time a customer requests and receives service. For example, when a customer places a call, a computer on board one vehicle answers the call and elicits the customer’s trip requirements. An auction then ensues among all vehicles (i.e. their computers) to select the best one to serve the trip and assume sole responsibility for it. Later, if circumstances warrant, another auction may reassign the trip. 1.2. ADART features ADART costs more than a bus but provides a better service; it costs less than a taxi and provides a lesser service. It ignores the off-the-street occasional users. From the customer’s point of view, ADART has four salient features or advantages: subscription use, many-to-few service, convenience and reliability. From the operator’s point of view, ADART’s important features include cashless/checkless revenue collection, fully automated dispatching, on-board information, command-and-control systems, high driver productivity, low operating overhead, and easy adaptability to demand. of this paper The remainder of this paper explicates the above claims. First we establish a hypothetical ADART operation as a context in which to explore details of the concept. Then we discuss ADART’s subscription process, present typical trip-making scenarios, and review classic DART service types. Next comes the paper’s essential message: fully automated dispatching, trip-end geocoding, and, most important, on-board distributed commandand-control-an idea that applies to a wide variety to transportation problems beyond dial-a-ride. Finally, after a discussion of ADART’s centralized call distribution and accounting systems, the paper ends with a listing of ADART benefits. 1.3. Organization

2. ADART

SUBSCRIPTION

Similar to a phone company, ADART requires that its users sign up beforehand. A new ADART customer can subscribe in person, over the phone, or via his personal computer. Having subscribed, he can use ADART for any trip between points in its service area. Unlike some existing DART operations, ADART subscription is not registering for a particular trip. ADART subscription merely entails paying subscription fees, providing credit and billing information, and furnishing data about routine trips. 2.1. Credit and billing

From order-entry to final billing, ADART accounting is electronic. Payment for service is via electronic funds transfer banks backing ADART customers’ credit cards (e.g. Visa/ Master Card). Alternatively, a subscriber may purchase a debit card or a check guarantee card. As we explain later, a passenger submits to an automated credit check with each trip request. Besides arranging for funds transfer, ADART subscription records routine “default” trip parameters and assigns a personal identification number (PIN) and identification (ID) card. ADART’s ID card gains access to ADART vehicles and automatic dispatching machines (ADMs) at ADART terminals. ADART’s PIN permits use of the trip reservation system. A customer can obtain multiple PINS and IDS, and may change his PIN at any time. 2.2. Routine

trip making

ADART provides a subscription service that offers several options. Among these is the option to serve routine trips, such as a daily two-way work commute. The customer can

Autonomous dial-a-ride transit

263

sign up for as many of these optional services as desired. Moreover, signing up for repeated trips will save money on each. Because it permits better resource allocation and route planning, ADART provides incentives for advanced trip scheduling. 2.3. Personal address list (PAL) Upon subscribing to ADART, the customer registers his personal address list (PAL) of common trip-ends (e.g. home, job, babysitter, etc.). The subscription process verifies, geocodes and files these addresses for the customer. Whenever the customer calls for ADART service, he can locate his trip-end by keying in a phone number or, alternatively, choosing an address in his PAL. In the former case, he does not need to key in the number of the phone he is using. In the latter case, he receives an audio prompt of his PAL entries and picks one by keying in a single digit. These prompts run from personalized user-specified scripts. For example, instead of the computer intoning a boring list of addresses, it says instead: “Enter one for home, two for work, three for day care,” etc. The customer can change his PAL at any time. 3. EXAMPLE SCENARIOS

Superficially, ADART resembles a minor variation of conventional DART service. Its only apparent difference is that service requests are via touch-tone telephone keys, and ADART can locate trip origins and destinations indirectly via phone numbers or directly via personal address lists. The following ADART trip-making scenarios exemplify these features. For brevity, these scenarios assume a many-to-one service: one end of every trip is the shopping mall. Later, we show how ADART readily provides MTF service. 3.1. Example 1: routine commuter travel

Mary lives in the suburbs and works in the city. She commutes by rapid rail. Each weekday, she goes to and from work at the same times. An ADART van, after its computer calls ahead 5 min earlier, routinely picks her up each morning and takes her to the nearest rail station. When she returns from work at night, a van awaits her at the station to take her home. To enter the van, she swipes her ID card and keys in her PIN. To leave the van, she swipes her card to authenticate her use of the service. ADART is not a taxi service. If Mary’s return train is late and arrives beyond her awaiting vehicle’s scheduled departure time, Mary will miss the van. She will pay for the missed trip since it was pre-scheduled. She will get a ride home by using the ADM to call up ADART. She will also pay for that trip. On the other hand, if Mary arrives early, and all her fellow travelers are on board, then the van will depart early. Mary arranged for this routine service when she subscribed to ADART. She can change it any time for a small fee. Unless her departure time in the morning or arrival time at night differs from normal, Mary never has to call ahead to ADART. Each month her Visa card shows payment for ADART’s usual monthly rate, plus charges for any additional ADART service used. 3.2. Example 2: shopping trip Joe, a lCyr-old student, lives in the suburbs. He enjoys going to the local mall to shop, snack and socialize. To make this trip, he calls ADART and responds to a few questions from a vehicles’ computer by keying in numbers on his phone’s touch-tone key pad. Information he provides includes: l l l

ID number and PIN (his father’s) trip origin, i.e. where he wants to be picked up (his home) earliest departure time.

If Joe were not calling from his desired trip origin, he would have entered that location’s phone number. In either case, he verifies that the address that ADART has for that phone number is in fact his desired pickup point.

Robert B. Dial

264

After furnishing these three data items, Joe learns the price of the ride and the approximate time the vehicle will arrive to pick him up to take him to the shopping mall. When Joe wants to return home, he goes to the ADART station at the mall and uses its ADM. He gives his destination by responding affirmatively to a prompt asking if he wishes to go home. Joe is told the number and departure time of the vehicle that will take him home. Joe’s father sees both trips on his next Visa bill. 3.3. Example 3: elderly and handicapped Pete is an elderly retiree. His eyesight is bad; he cannot drive. He has medical appointments at the clinic located in the mall. To make these trips, Pete does what Joe did, except that he specifies the time he needs to arrive at the destination. He also requests an added service: he wants to be called 15 min before the vehicle arrives, so that he has adequate time to prepare. If Pete knows when he will be returning home, he can save time and money by pre-scheduling his return. Otherwise, Pete returns home the same way as Joe. 3.4. More examples Example 4: personal business. Mary and Betty both live in an ADART

service area. They are socializing at Mary’s place. When Betty is ready to leave, she calls ADART and requests an ASAP pick-up at Mary’s house, which she locates by its phone. ADART picks her up on time and takes her to the mall. From there, she goes home the same way Joe and Pete did. Her trip home is indirect (i.e. via the mall) because ADART is not “many-to-many.” Example 5: childcare. If Betty had grade-school children at the baby sitter’s, she could have ADART pick them up and take them to the mall, where she would meet them. Example 6: group travel. Harry is taking his two children to a movie at the mall. When he calls ADART, he says that there are three people in his party. As Harry and his kids board the vehicle, the driver enters the party’s size on his key pad. Harry acknowledges this by swiping his ADART ID card through the vehicle’s card reader and entering his PIN. Harry’s ADART bill will reflect this three-person trip. Example 7: personal business. At the mall, Henry decides to visit his mother. He calls ADART and responds to his PAL prompt with his mother’s address. He returns home the same way as Betty. Example 8: ofithe-street demand. While walking toward the mall, George, an ADART subscriber, sees an ADART vehicle approaching. He waves at it to stop and give him a ride, but it does not stop: ADART only serves pre-arranged trips. Unscheduled pickups can cause unplanned delays and seating problems. For a ride, George must hail a taxi or find a phone. 3.5. Summary

All preceding examples repeat the same sequence of events. For on-demand access to service, ADART uses PALS and phone numbers to locate trip-ends, and customers use: l l

l l

their ID and PIN to arrange for travel by phone; their phone’s touch-tone keys or an ADM to relate their trip requirements: origin (destination), earliest departure (latest arrival) time, and passenger count; their ID card to board and deboard the vehicle; their bank cards to automatically pay for service.

Normally, all these transactions involve only the passenger and a computer. 4. TYPES OF DART SERVICE

Having established a hypothetical service policy, our technical discussion of ADART begins with a brief review of the classical taxonomy of dial-a-ride service. Conventional DART falls into one of three broad categories: many-to-one, many-to-few and many-to-

Autonomous

dial-a-ride

transit

265

many. All three imply two-way service. Although ADART works for each, many-to-few appears the most promising. 4.1. Many-to-one (MTO) MT0 was the type of service assumed in the sample scenarios described above. The simplest service to provide, it transports passengers to or from many locations (e.g. residences) to one location (e.g. shopping mall). The user of MT0 service has only to provide one trip-end location from the “many;” the other end of his trip is always the “one.” To serve its riders, the vehicle’s MT0 route varies according to demand; however, its terminus (origin or destination) is always at a specific point in the mall. Thus, it is relatively easy to compose good routes and schedules for MT0 service. While easiest to service, MT0 restricts itself to a small segment of travel demand. 4.2. Many-to-few (MTF) In contrast to MT0 service, MTF serves more than one attraction center, and is harder to provide. The term MTF applies when either the centers are clustered in close proximity or scattered far apart. ADART readily handles both cases. When clustered, the centers are close enough together that MTF reduces to MT0 service with a short fixed route at the terminus, from which the rider debarks at his pleasure. One common example would be three stops at the same, large shopping mall. For scattered centers, each center receives separate and distinct treatment when ADART obtains the caller’s destination choice. To serve multiple centers requires only a simple audio menu prompt (e.g. “if you wish to go to Tyson’s Corner, press one; to the Metro station, press two; to Seven Corners, press three”). This approach is practical for up to 10 centers, which is adequate for substantial coverage. Naturally, if the caller already knows his selection, he need not listen to the whole prompt. Every city has several market segments of its traveling public that MTF service can target. Since many trips go from home to some attraction center, MTF coverage is high enough to attract sufficient ridership, which maintain vehicle load factors that sustain service at moderate cost. This makes MTF the most cost-effective form of DART. Accordingly, this paper presumes that ADART is an MTF service. 4.3. Many-to-many (MTM) To date, taxis are the mode of choice for MTM service, and their high fares reflect their low productivity. In fact, ADART applies to MTM as easily as MTF; however, because of the scatter of both trip-ends, MTM cannot consolidate trips to the extent that MTF does. As a result, load factors are low, which dictate correspondingly high fares, which in turn reduce ridership. It seems, therefore, that ADART would be much less successful providing MTM than MTF service. 4.4. Multi-vehicle service areas

The best dial-a-ride systems allow more than one vehicle to pick up passengers within the same service area. In contrast, to simplify dispatching, the most demand-responsive systems partition a service area into non-overlapping sub-areas, and assign sub-area coverage exclusively to a single vehicle. Single-vehicle coverage. Because service reliability is a feature that customers value highly, it is dangerous to assign exclusive coverage of a geographic sub-area to one vehicle. Three cases below illustrate this point: l

l

l

a vehicle is at the left edge of its large service sub-area when it has to pick up a passenger at the right edge; a surge of demand in one sub-area overwhelms the capacity of its assigned vehicle to serve it; a breakdown or accident puts a vehicle out of service.

266

Robert B. Dial

The first problem can cause the vehicle to take an unproductive route (low trips/mile), make the customer wait beyond a reasonable time, be late for the pickup, or miss the trip entirely, which would be a disastrous service failure. All three problems renege on expected service. An “unreasonable wait” is a scheduled arrival that is too distant in the future; a “late pickup” is an arrival later than scheduled. Service failures occur with varying severity. Being a little late is presumably less grave than not showing up at all. In the first case, in recompense for his inconvenience, the rider should have all charges waived for that trip. To avoid the second case, the dispatcher calls taxi to service the trip at DART’s expense. Service failures deal fatal blows to any enterprise. Destroying the user’s trust and goodwill, they cause lost ridership. For a single vehicle to avoid these service failures, its sub-area must be small. Unfortunately, small sub-areas result in large fleets and small load factors, which lead to financial disaster. Multi-vehicle coverage. By assigning multiple vehicles to the same service area, DART can assign a trip to the vehicle that most efficiently serves it. This assignment depends on the present and planned locations of all vehicles. In this way: l l

l

another vehicle can pick up a trip otherwise assigned to a vehicle unable to serve it; fewer vehicles are needed, since their flexible coverage allows them to cover larger areas without risk of service failure, resulting in higher load factors; vehicle breakdowns are handled in a “fail-soft” manner, since the impacted trips can be redistributed automatically among the remaining vehicles until a replacement vehicle arrives, causing minimal service delay instead of large-scale service failures. 5. FULLY AUTOMATED DISPATCHING

A fully automated dispatching (FAD) system is one that can field a customer’s request for service, schedule a vehicle to provide that service, and optimally route the vehicle without any human interaction. That is, the customer is the only human involved in the entire process of requesting a ride, scheduling arrivals and routing the vehicle. There are no telephone operators to receive trip requests, no centralized dispatchers to assign trips to vehicles, and the driver merely obeys the instructions issued by the vehicle’s computer. The vehicle’s on-board computer receives a customer request, inserts this request into the vehicle’s schedule, and plans an optimal route to accomplish the schedule. Furthermore, if beneficial to do so, the computer may pass the request off to another DART vehicle, without the drivers knowing it. To describe this process, we now view the preceding scenarios from the perspective of the computer. After discussing the automated user-interface, we present a brief review of computer-assisted vehicle navigation, and lastly address the routing-and-scheduling activities. 5.1. User interface Order entry. When a customer calls, a computer on board a vehicle answers the phone.

Routed to a vehicle by an automated central distribution system, the call arrives with its origin’s phone number, which is converted into a street address. An ID number and PIN provide customer data, including credit standing. Touch-tone key input describing trip requirements furnishes the rest. Having the customer’s ID and his phone’s number, the computer uses the customer’s PAL to prompt for the destination’s street address (or a phone number that it converts into that street address), makes revisions to its route, and posts data for billing. Scheduling. Regarding departure or arrival time requirements, the computer knows the vehicle’s scheduled whereabouts, as decided from its schedule of all outstanding trips. By inserting the new trip into its vehicle’s schedule, the computer estimates the customer’s earliest pickup or arrival time and compares it with the request. After conversing briefly with other computers, the computer then informs the customer accordingly.

Autonomous dial-a-ride transit

261

Cull-ahead. To assure minimal dwell time, the computer schedules itseif to call the customer at a specified number of minutes before arriving at the pickup point. At that time, the computer will trigger the phone call and its voice unit to tell the customer the precise time of its imminent pickup. Pickup and delivery. When the pickup occurs, the computer notes the passenger’s arrival from his ID card, read when the passenger boards. When the passenger reaches his destination and swipes his card, the computer initiates the process of billing the customer and receiving payment electronically. Route optimization. Meanwhile, the computer is working hard to optimize its vehicle’s route.

5.2. Vehicle navigation The vehicle’s navigation system (VNS) consists of a computer and other special purpose hardware on board the vehicle (see French, 1986). The VNS tracks a vehicle’s current location in reference to latitude and longitude (LL) and the road network. It gets this knowledge by receiving a periodic LL fix from global positioning satellites (GPS) and locating it on a digital vectorized model of the road network stored as data on the vehicle. For purposes of precision and reliability, ADART uses both GPS (see e.g. Wells, 1987) and dead-reckoning (see e.g. Shufeldt and Dunlap, 1970) to track the vehicle’s position on the road network. The GPS system consists of 24-plus satellites, continuously emitting their location in space. Their orbits provide visibility of four satellites from anywhere in the earth’s biosphere at any time. Knowing the location of four satellites, it is possible to determine with the location of a receiver of this information. Theoretically, then a vehicle with an onboard GPS receiver always knows its location. In practice, unfortunately, this is not the case. A GPS satellite can temporarily go out of service, and more important, a GPS receiver must be visible to the satellites. Therefore, even if the GPS system were completely reliable, its signal would not reach a vehicle indoors, nor in a tunnel, nor under trees, nor on street flanked by high buildings, etc. Dead reckoning involves a vehicle tracking itself with only on-board equipment. Wheel sensors act as a differential odometer, and a magnetic flux reader relays its compass orientation. Along with a clock, these items provide the vehicle’s direction and speed. When the GPS signal is blocked or inoperative, dead reckoning works alone. When the GPS signal is present and visible, it corrects any accumulated dead reckoning error. The road network’s description resides in the vehicle as a digital map. This digital map is nothing more than a file of street segments. Two’adjacent intersections define each street segment. These intersections depict the network’s connectivity, or topology. Besides the LLs of its intersections, each street segment has an estimate of the expected speed at which a vehicle may traverse that segment. With these data, the computer can decide the best path between any two points in the network, and figure out the time the path would require. Vehicle trucking and data logging. The VNS continuously outputs position updates to a display monitor in the vehicle that shows the vehicle moving along a map of the roads in its vicinity. Because road names also appear on the monitor, the driver always knows his exact location. This display also informs the driver of the path he is to follow, and, when appropriate, shows the location of his next pickup and expected time of arrival. In addition, the vehicle’s computer continually logs its location history to a disk file, which provides data to analyze the driver’s performance and to help improve future system performance. Command-and-control. Knowing the vehicle’s location, the FAD can plan the vehicle’s itinerary from any point in time, give the driver directions, and monitor his compliance. In effect, the vehicle-and its driver-is merely a device under the control of its routingand-scheduling system. 5.3. Routing-and-scheduling Using every free computer cycle, the routing-and-scheduling system (RSS) continually works to improve the planned route of the vehicle to fulfill its outstanding trips. The

268

Robert B. Dial

RSS’s goal is simply to devise an itinerary for the vehicle to pick up and deliver would-be passengers according to their origin/destination and time-window requirements at minimum cost (see e.g. Bodin et al., 1983). In practice, however, accomplishing this goal is not very simple. Even with off-line computation, routing and scheduling several trips with time-window constraints over a large road network poses a formidable computing challenge. For an online operation like ADART, it is much more difficult. The RSS is aiming at a moving target. After composing an excellent route for its vehicle, the RSS might receive a new trip, whose inclusion destroys the viability of the planned route. Furthermore, the computer has limited time to find a feasible solution-never mind optimal. Using dynamic programming (see Psaraftis, 1980) a large fast computer can meet this challenge, provided the number of trips to process is small. In ADART’s case, this number is kept small by three algorithmic expedients: l l l

focus attention on trips needing service in the near future; delay informing the driver of any decision as long as possible; consider only trips in the dispatch of a single vehicle.

The first item discounts the importance of far-future trips, since any early plans for these trips would most likely be upset by new trip demands. The second item permits the RSS to absorb a maximum amount of data and to change its mind several times before committing to a route. The third item needs a discussion of an ADART straightforward routingand-scheduling algorithm. Vehicle assignment. Whenever a user calls the ADART phone number, all ADART vehicles await the call. The first vehicle’s computer to receive the call prompts trip data from the customer. This initial vehicle’s computer (VC) then initiates an “auction” for the trip: 1. It begins by estimating its “marginal cost” (e.g. expected miles/trip) of including that trip into its vehicle’s schedule. Its computer figures this cost by inserting the trip into its vehicle’s planned route, or some variation of it, in a way that assures the vehicle meeting all its scheduled arrivals. 2. Then it broadcasts this cost and the trip’s requirements to every vehicle serving the same sub-area. Each of these latter VCs makes its own estimate of including the trip in its own itinerary. Any VC whose estimate is lower than the initial VC’s responds with its own cost. Others remain silent. 3. Finally it informs the VC with the lowest cost of its responsibility for the trip. All other VCs ignore the trip. The responsible VC enters the trip into its scheduling system, which grinds away toward an optimal route to serve all its currently assigned trips. In technical parlance, the VCs collectively assign the new trip to a “cluster” belonging to the responsible vehicle, thus leaving each VC to solve only one small traveling salesman problem (TSP). Furthermore, all the vehicles’ computers work on their particular TSP in parallel. This decomposes an otherwise huge, daunting problem into several easier small problems-all solved simultaneously-and enables an ADART operation to keep up with even the largest demand surges. Note that no human participates in trip-vehicle assignment, routing or scheduling: not the driver, not the customer, and certainly not any dispatcher. Trip-vehicle reassignment. Another, important application of this auction algorithm is a simple on-the-fly expedient that improves productivity and reduces service delays. When a vehicle’s projected productivity drops below some critical threshold, the “problem trip,” whose exclusion would net the largest cost saving is put up for auction, so that a better positioned vehicle might service it. Vehicle and service failure. This same auction algorithm supports fail-soft measures when a vehicle unpredictably goes out of service. Here, all the disabled vehicle’s trips are

Autonomous dial-a-ride transit

269

auctioned off to the remaining vehicles. In the rare event that an accepted request later becomes unserviceable, the responsible VC calls a taxi for the trip. Caveat. The auction algorithm proposed above is a preliminary strategy, which with more study will undergo significant refinement. For example, as issues and options regarding communications hardware and protocols clarify, it will become obvious where to trade-off vehicle autonomy for efficiency. It appears now, however, that each VC can operate in virtual ignorance of the state of the other vehicles, while at the same time cooperate with all the other VC’s towards minimizing the total cost of servicing all trips. This is the ideal. 6. TRIP-END GEOCODING

To ADART, “geocoding” means associating a trip-end with a location on the road network. A key in achieving an effective on-line FAD is the decision to use phone numbers and address menus for geocoding. This decision, admittedly, restricts the service potential of ADART vis-ri-visconventional DART a little. However, restricting FAD to phone numbers and address lists precludes getting bogged down in the ever painful and problematic interpretation of random street addresses. 6.1. On-line geocoding

On-line geocoding means encoding trip-ends while the vehicle is servicing them. Whatever the input medium, street addresses composed by humans are rife with spelling and permutation inconsistencies, and are often bogus (i.e. do not even exist as locations). Teasing a good address out of bad input is time consuming, difficult, and risky business. It is a task unsuited for an on-line operation. 6.2. Phone-number geocoding

On the other hand, the phone company knows the locations of its (non-mobile) phones. The phone locations that ADART serves can be electronically posted on digital mapsbefore ADART vehicles reference them. If a phone number is not in the list of a vehicle’s service area, ADART rejects it as a trip-end. This prevents the caller entering a bogus address that sends the computer (or, even worse, the ADART vehicle) on a proverbial wild goose chase. Even a mobile phone could be used to request ADART service, provided it transmitted the LL of its location. Some brands of mobile units may already have this capability; it would be easy to construct a phone accessing GPS. ADART would only have to receive the LL, locate it on the street map, and feedback a response with a reasonable description of the pick-up point-as a street address, intersection or place name. 6.3. Of-line address geocoding

Privacy considerations preclude geocoding all phone numbers, and a PAL has only a few addresses. How then does an ADART user specify an address that cannot be associated with a phone number and is not on his PAL? Answer: he must accomplish this geocoding off-line. Off-line geocoding means locating trip-ends leisurely, without the demanding time constraints an on-line operation imposes. Here, the customer uses a stand-alone geocoding work station, which can verify any address and optionally log ADART travel requests. These stations exist at ADART terminals. The customer also can use his own computer for off-line geocoding, having received the software for a small fee upon subscribing to ADART. Off-line address geocoding is an invaluable capability. Several commercial systems are available. ADART could run without it. However, the ADART subscription process needs state-of-the-art address geocoding workstations to compose and authenticate PALS. Thus, this same software would be readily available and should be shared with customers.

270

Robert B. Dial 7. ON-BOARDCOMMAND-AND-CONTROL

Except for FAD and some address restrictions, ADART appears conventional. But an automated centrally dispatched DART is not ADART. ADART’s distinguishing feature is having all of its information, command-and-control systems (IC2) on board the vehicle. On-board IC2 requires that each vehicle carries all computing and communications hardware and software necessary for FAD. Low prices of fast computers with large RAM and disk storage enable this. 7.1. On-board hardware Each vehicle carries a full complement of computing hardware and data. The hardware, all off-the-shelf, includes: a general purpose computer for routing and scheduling, vehicle navigation hardware for monitoring the vehicle’s location and communicating it to the driver and the routing-and-scheduling system, l communications equipment for carrying information between customers, vehicles, and computers, l cellular telephone for both routine and emergency communication with the driver. l

7.2. On-board data On-board data is extensive but practical due to inexpensive massive data storage devices, off-the-shelf digital road maps, geocoding files, and robust database software. Onboard data files include a trip database, a partial customer database, a complete vectorized road network and a service log. Data acquisition. Inexpensive vectorized road networks are available from several geographical information system (GIS) vendors, who also provide address and placename geocoding files (see Dial, 1986). The phone company furnishes phone geocoding files. ADART generates the service log automatically. File maintenance. All the above files will require maintenance-updating and backup. For example, it is likely that ADART drivers will detect errors in the road network database. The ADART file maintenance system would provide the means for using these driver observations to update the network database in all vehicles. Note that ADART does not have the infamous “distributed database problem:” all of its “shared data” are static. 7.3. On-board software The on-board ADART software systems fall into five general classes: order-entry, vehicle navigation, routing-and-scheduling and communications. The functionality of all this software should be clear by now, except perhaps for communications software. Communications. The communications hardware and software establish three connections [for introduction to wireless communications, see Feuerstein and Rappaport (1993)]: l

l

l

Vehicle-customer. Under normal conditions, all vehicle-customer communications go on between a computer and the customer. In rare emergencies, the driver communicates with a calling customer. Vehicle-vehicle. A mobile radio via the modem carries and receives broadcast messages from other vehicles, primarily for allocating customers among vehicles in systems where multiple vehicles operate in the same service area. Vehicle-base station. A radio-modem sends and receives messages to and from the base station, primarily for fetching customer data from the Central Accounting System (see Section No. 8) and secondarily for vehicle tracking at the base station when desired. A cellular phone provides back-up emergency communications when a vehicle’s computer system goes down.

ADART, of course, does not require centralized vehicle tracking and works best without it. We show later that detailed observation of vehicle movements is done most costeffectively after the fact, using data logs to drive display monitors.

Autonomous dial-a-ride transit

271

Remark: software development. While vehicle navigation systems are available off-theshelf, no existing commercial routing-and-scheduling package meets ADART’s requirements. Consequently, routing-and-scheduling software must be built. Because efficient algorithm design and reliable real-time code are software engineering’s biggest challenges, this software’s construction requires a high capital investment. Its cost becomes insignificant, however, when divided by the large number of vehicles that could use the software. 8. CENTRALIZED

SERVICES

ADART does require some centralized services (alas!). While a totally distributed diala-ride operation would be admirably robust and uniquely elegant, it would not be practical. Decentralized order-entry, navigation and routing-and-scheduling are clearly advantageous; however, certain other services function much better centralized. Centralized call distribution and accounting systems guarantee data currency, integrity and fast access by: l

l l l l l l

maintaining an updated customer database, including PALS, credit-risk flags and billing information, handling customer rejections due to bad credit, enlisting human assistance for “touchy” situations, sending bills and collecting payment, communicating with vehicles efficiently and quickly, tolerating faulty communications and/or system faults, and expanding easily.

8.1. Centralized call distribution system (CDS) The ADART CDS is a simple, single purpose system that automatically (i.e. without dialog) routes all incoming calls to vehicles. That is, a customer calls the CDS, but a vehicle’s computer answers the phone. While the CDS function is obvious and warrants no further comment, other, more complex centralized ADART services merit discussion. These latter services are the responsibility of the central accounting system. 8.2. Centralized accounting system (CAS) Efficient file maintenance and data security dictate centralizing customer database management and accounting functions. Communications traffic between the CAS and vehicles is the price ADART pays for data integrity and easy accounting. ADART keeps this traffic at a minimum by downloading on demand a calling customer’s data to the VC engaging the customer in order-entry dialog. The VC simply fetches the customer’s PAL data from the CAS. Entailing no Q&A, this transaction is “short and sweet.” The CAS is simply a file server(s), whose capacity is readily increased as demand requires. To ensure reliability, the CAS is fault-tolerant. Communications traffic between it and vehicles is minimal. Each call is a simple data transfer of short deterministic length. The CAS receives no more than two calls per customer. On rare occasions, the CAS will call back the VC once; however, in this case the second call from the VC will likely be avoided. Thus, in a booming ADART operations serving 5000 customers a day, the VC and CAS will exchange as few as 10,000 and no more than 15,000 messages. Customer credit check. When the CAS receives the VC’s PAL request, it checks its local data for a credit-risk flag on the customer. If it finds one, it informs the VC not to serve the customer. Otherwise, it downloads the requested PAL data and initiates an asynchronous remote credit check on the customer. If this remote check is positive, the CAS does nothing. Otherwise, it flags the customer as a credit-risk, informs the VC, and phones the customer to refuse service. 8.3. (Dissenting) remark: remote vehicle tracking Each VC could easily transmit its current location and status to a remote base station, which would display on a CRT the real-time movement of ADART vehicles on the street

212

Robert B. Dial

network. While amusing and glitzy, the benefit of this passive tracking display has dubious utility, unless the display is a control mechanism. Otherwise, it seems a high-tech waste of time, money, cycles and bandwidth; since, by design, the base station has no control over the vehicle’s operation. It would appear that a better way to analyze vehicle movements is to study them after the fact by playing animations off vehicle data logs. Then the analyst can observe operations repeatedly and faster than real time. He can juxtapose one vehicle’s operation on different days, alter the routes manually, or watch the effects of alternative routing algorithms. Furthermore, if vehicles relay their position with each message to the CAS, then a coarse-grain real-time tracking is available “for free.” The above notwithstanding, it will doubtless be required to provide high-fidelity realtime tracking. To avoid adverse effects on the ADART operation, the system should track only specified vehicles and do it with a dedicated processor, which uses sophisticated algorithms to minimize data communications. 9. ADART BENEFITS

ADART’s distributed arsenal of hardware, software and data brings three-fold benefits: technical, operational and financial. 9.1. Technical benefits Distributed computing and simple vehicle-to-vehicle communications dispatching, lower communications traffic, and high reliability: l

l

l

yield efficient

Eficient

dispatching. An ADART fleet’s combined computer power permits the implementation of sophisticated parallel decomposition algorithms to approximate globally optimal vehicle itineraries. The principal technical benefit is efficient dispatching-no matter how high the demand. High reliability. The trip-auction algorithm readily handles vehicle failures. Except for the CDS and CAS, which are easily made fault-tolerant, ADART has no failure point that can bring down the whole operation-a vulnerability that every centralized system suffers. Low communications trujic. Compared to conventional systems, ADART creates less communications traffic. This saving results from ADART’s on-board IC2, which obviates centralized vehicle tracking. Except for the customer’s phone call and trivial PAL downloading, ADART’s only major mobile communication is for tripvehicle assignment auctions.

Assuming even the most simple-minded broadcast protocol and highest frequency of trip swapping, these auction messages generate a small fraction of the traffic a conventional system produces merely to track its vehicles. A more intelligent approach would create even fewer auction messages; however, this would require each vehicle having knowledge of one or more of the other vehicles, reducing vehicle autonomy. 9.2. Operational benefits Ease of expansion. ADART brings numerous operational benefits. Its most important is ease of expansion. Because the cost of running an ADART operation is linear in the number of vehicles, ADART can do something conventional DART could not-grow and service very large demand efficiently. For innovative transit service, ease of expansion is crucial: it is difficult to forecast the pace and magnitude of change in demand. Upon the service’s introduction, demand is low but eventually ramps up to a stable level, as customers learn the system and develop sufficient confidence in it to modify their travel behavior. The ideal transit operation expends resources in direct proportion to the demand for service. For a centralized system, however, this ideal is impossible. A centralized system must forecast, budget and program resources. It has to allocate people, space and hardware

Autonomousdial-a-ridetransit

273

several months in advance, and these allocations once in place resist change. While demand is low, a centralized system is lavishly overequipped, and when demand increases beyond forecasted levels, it cannot adapt fast enough to service it. An ADART system, by contrast, grows simply and cheaply. It can start by putting a single vehicle in service. If increases in demand warrant adding a vehicle, another vehicle simply joins the fleet to become a productive member of the team immediately. The new vehicle brings with it all the additional hardware and software needed to guarantee service for the new demand. Of course, these same arguments apply to the routine daily fluctuations in demand that bring vehicles in and out of service. Better security. Beside the superior passenger security implicit with doorstep service, ADART improves security for people both inside and outside the vehicle. For example, the on-board computer permits the driver to alert the police by only pressing a single key, which automatically dials 911 to report a particular incident type occurring at the LL where the hot key was pressed. This message includes the number of the driver’s cell phone, in case the police needed to call back for further clarification. Other operational benejits. Besides ease of expansion, ADART possesses additional operational attributes. ADART’s omissions are its strategic benefits; its high level of automation provides tactical benefits. For example, ADART can: l

l

l

l

minimize centralization to eliminate queues and system “crashes,” whereas centralized systems create queues, lack robustness, and can be brought to a standstill by a single failure; simplify communications, which minimizes paperwork, reduces human intervention and improves productivity; eliminate large centralized data processing facilities, with their management bureaucracy and costly adaptation to change; support frequent customer-satisfaction surveys that are convenient, fast, inexpensive, and fully automated.

ADART’s system performance can continually improve. Using ADART data logs, analysts can review the prior behavior of vehicles and passengers to test out new improved policies. One potential application of this wealth of historical data ADART captures in the course of its operation is for dispatching algorithms that are adaptive. Adaptive algorithms can observe their own past performance with the aim of changing their tactics. A simple example is the anticipation of future demands based on the demands for a similar day or group of days in the past. Extended utility. Being a formidable armada of networked computers on wheels, ADART has potential utility beyond the many-to-few dial-a-ride application forming the basis of this paper. Some of its ideas would find good use in route-diviating and interlining buses, local police cruisers and package delivery vans. Most apply even to driverless systems, such as personal rapid transit and dual mode. Furthermore, the ADART vehicle would be a natural and grateful recipient of real-time highway speed information, and it would serve well as a “probe” to provide this information to others. 9.3. Financial benefits With its higher productivity, lower manpower, and improved service, ADART promises direct and indirect financial benefits. It: l

l

l

l

allows several vehicles to optimally cover the same service area, by bringing to bear its immense computing power and a massive information base; needs fewer people than a conventional demand-responsive service, by having no telephone operators, no dispatchers, no driver supervisors, and minimal accounting/ clerical support; reduces driver error and training costs, by monitoring and directing each driver through his entire workday; creates new revenue for existing transit, by linking low-density residential areas to high-speed fixed-route transit systems.

274

Robert B. Dial

The plummeting costs of computer hardware, mobile communications and vehicle navigation place the cost of ADART vehicles within the budgets of transit operations. Case in point: in Boston, MBTA’s “The Ride” uses a van that, with volume discount, costs $32,000, which is about half the fully loaded annual cost of the driver. Of this $32,000, $20,000 is for the base vehicle and the remainder for special equipment. With its computers, an ADART vehicle will cost lo-15% cent more, thus paying for itself as soon as it yielded a one-time reduction in personnel cost or increase in revenue of about $3000-a tiny fraction of any transit operation’s budget. 9.4. Remark: privatization This paper has tacitly assumed that ADART is a publicly owned and operated system; however, nothing relies on this assumption. Other options exist. The ADART idea could benefit an otherwise normal taxi operation providing either exclusive or shared-ride services. Another possibility is to offer ADART vehicle franchises. Franchising individual vehicles, however, brings special management problems. A more likely alternative is to award a franchise for an entire geographic area to a private corporation. This corporation would maintain and operate a large ADART fleet according to a fare and service policy that the local transit commission dictates and ADART’s on-board computers implement. 10. CONCLUSION

ADART is a demand-responsive transit service that has fully automated dispatching and autonomously managed vehicles carrying all of their command-and-control facilities on board. By combining available technology with an autonomous dial-a-ride vehicle, ADART should raise reliability and productivity levels and reduce labor needs. Applicable to private, public or quasi-public operation of a variety of service types, autonomous dial-a-ride is a flexible system that may be the answer for transit service to low-density areas, serving a host of happy customers at a satisfactory cost to consumer and supplier alike. Of course, substantiation of this claim requires site- and service-specific demand studies, simulations and service demonstrations. Nonetheless, ADART is “an idea whose time has come” and merits additional study to put technical substance behind the abstractions this paper presents. Acknowledgemenrs - The Advanced Public Transportation Systems (APTS) program and the Livable Communities Initiative of the Federal Transit Administration (FTA) sponsored this paper. Individuals who read the first draft and noted unanswered questions or weak arguments were Ron Fisher of the FTA (now retired), Dan Brand of Charles River Associates, Franc0 Vitalliano of VXM Technologies, Inc., and my Volpe Center colleagues Marc Bucciarelli, Bob Casey, Mike Jacobs, Bobby Ow and Gary Ritter. Editor-in-Chief Stephen Ritchie and an astute but anonymous referee suggested several improvements to the paper. Bob Brodesky, of EG&G. Dynatrend Corporation, edited the paper and repaired my typing and grammatical blunders. Any persisting errors in content or form are mine.

REFERENCES Bodin L. D., Golden B. L., Assad A. and Ball M. (1983) Routing and scheduling of vehicles and crews: the state of the art. Computers Opus Res. 10,69-211. Dial R. B. (1986). The Etak digital map database: potential applications in planning and operations. Technology Options for Highway Transporration Operations. Department of Civil Engineering, University of California at Berkeley, CA. Feuerstein M. J. and Rappaport T. S. (1993) Wireless Personal Communications. Kluwer Academic Publishers, Boston, MA. French R. L. (1986). Historical overview of vehicular navigation and route guidance technology. Technology Options for Highway Transportation Operations. Department of Civil Engineering, University of California at Berkeley, CA. Jaw J.-L., Odoni A. R., Psaraftis H. N. and Wilson N. H. M. (1986) A heuristic algorithm for the multi-vehicle advance request dial-a-ride problem with time windows. Transpn Res.-B 20, 243-257. Psaraftis H. N. (1983) A dynamic programming solution to the single vehicle many-to-many imeddiate request dial-a-ride problem. Trunspn Sci. 17, 351-357. Shufeldt H. H. and Dunlap G. D. (1970) Hotingnnd DeadReckoning. United States Naval Institute, Annapolis, MD.

Autonomous dial-a-ride transit

215

Wells D. (1987) Guide to GPS Posifioning. Canadian GPS Associates, Frederiction, New Brunswick. Wilson N. H. M. and Sussman J. M. (1971) Scheduling algorithms for dial-a-ride systems. Urban Systems Laboratory Report USL TR-70-13, MIT, Cambridge, MA. Wilson N. H. M. and Roos D. (1971) Dial-a-ride: an overview of a new demand-responsive transportation system. Urban Systems Laboratory Report USL TR-71-03, MIT, Cambridge, MA.