CA2001588A1 - Transportation dispatch and delivery tracking system - Google Patents

Abstract

ABSTRACT OF THE INVENTION

An integrated vehicle dispatch system that performs the management, coordination and communication functions for dispatching vehicles. The system include a plurality of microcomputers interconnected via a "BITBUS" network, such that a fully redundant capability is provided. Each of the workstations control text and or graphics monitors. Information in the graphics monitors are based upon a digitized map base, such as the U.S. Census Bureau GBF file or "DIME File" of the vehicle delivery areas, such that vehicle pickup, deliveries, minimum path routes and vehicles delivery zones are displayed in an icon-based format.
The software of the system calculates minimum travel time based upon a tree-node decision algorithm that matches street distances, and travel times to real traffic conditions. Candidate vehicles for pickups and deliveries are selected upon a user-defined set of factors that include time, speed, vehicle characteristics and distance factors. The software also includes a fully integrated third party billing and business operations accounting package that enables fully automated dispatch system operation.

Description

~ r~.rj~ ~

TECHNICAL FIELD OF THE INVENTION

The following invention involves a computer integrated dispatch routing and operations management system designed for use ln emergency and non-emergency vehicle delivery en~ironments.

. .

, . ~,., ' BACKGROUND OF THE INVENT_ON

With the advent of computer technology, vehicle dispatching systems have been developed to more adequately track the location and movemen~ o~ a varie~y of delivery vehicles.
Despite the a~ded e~ficiency provided by computer hardware, many problems still remain. one of the most critical of these is providing a delivery system that employs its resources as efficiently as possible.

One of the most difficult efficiency problems is the need to dispatch vehicles from point to point in response to random~
orders. In typical vehicle delivery environments, call~ arrive at vehiclQ dispatch centers at var~ous times. The pick up and delivery times and locations of these calls cannot necessarily be predicted in advance. In terms of the computer systems designed to handle deliveries, the~e calls axe known as asynchronous events, i.e., occur randomly. Such events call upon the computer system which manages them to operate in ~Ireal-time~.

The various attempts to computerize dispatch, incorporate the same artifices used in manual operation~ and prejudice the optimality of vehicle assignments to random events. ThPse prejudices take the form of constraining the operation of vehicles in time or space. As an example o~ these constraints, a courier or cartage vehicle may be restricted to delivering in the morninq and picking up materials in the afternoon. Space constraints can i ~ ' : , ' ' Z~ rj~

be al50 characterized by the use of zones circumscribing the allowed operational territory for each vehicle.

The reason that these constraint~ prejudice optimization is that they eliminate the dispatcher~ oppoxtunities to capitalize on these various random even~s. For example, a vehicle may be picking up something in one zone and then delivering the item to a second ~one outside its own territory. Thus, it may be preferable to assign that vehicle to a new pick up in the second zone, rather than having the vehicle returned to the original zone. Such time and space constraints can cause inef~icient use of the transport resources and possibly overload or under-utilize equipment. 4 A further ef~iciency problem with current computerized dispatch systems is th~ ef~icient alloca~ion o~ resources in order to maximize vehicle response time~ A dispatch operation is predicated on the ability to consistently judge the time and location factors associated with each event. It is simple for current systems to match a single address to a single location in space. However, it becomes harder for such systems when one or several vehicles are moving at the same time and three ox four locations are being delivered to simultaneously.

To overcome the respon~e problem, the computer system must provide a mean~ of reproducing all of the l'cognitive" processes in a manual system that are required to e~ectively meet the various utilization conditions. In other words, the system must factor in several considerations to the decision: the time and space .
.

.

~f~r~

implication of each event, the dispatching decision to assign the resources, and the capability of reportiny the status simultaneously to all resources~

A further efficiency probl~m relate~ to the lack of computer systems which can integrate the management and the allocation of resources and effectively communicate decisions . system-wide. There is also a need for a system which not only handles the basic management tasks, but succes~fully intsgrates a plurality o~ ancillary functions. Such ~unctions include:
address location work, point-to-point travel time estimation based upon road network and expected traffic conditions, and the communication of vital in~ormation to customer The prior art does not have any integrated system~ that overcome these problems and that also integrate thes~ ancillary functions.

As discussed, there are sev~ral delivery systems which coordinate vehicle di~patching. One such system is the CABMATE
manufactured by the Gandalf Systems Group, 350 East Dundee Road, Wheeling, Illinois. CABMATE consists of a Dispatch Terminal set up in a driver dash-mounted computer terminal linked by radio transceiver to a host dispatcher's computer. The options available in the CABMATE System include customized city street directory, interface capability with accounting software, an integrated parcel dispatching system and an option which allows driver~ to queue into the open available cab list be~ore a fare is completed.

. - 4 :~ -~ ~ , ~n~r~

The Gandalf System, however, does not provide for any resource which optimizes the utilization of vehicles. Thus, dispatchers are not provided with optimal paths or any graphic displays of the City MapsO Cab~ are selected using a ~irst in fir~t out system ~ro~ the local queue based upon the last fare delivered. Thus, selection of cab~ for ares is independent of their location.

Another mobile terminal is available from Motorola, which provides a RDT portable terminal 800 Series for message processing. The Motorola system is used primarily in inventory and business application Some of the ~eatures of the ~otorola software include a servic~ history review program, order statu~
screen, billing information displays, inventory control and dynamic real-time scheduling. ~owever, vehicle management functions which allow ~or priority based dispatching and allocation are not aspects of the Motorola program.

, . .

~2S)1~

SUMMARY OF_THE INVENTION

It iR, there~vre, an object o~ the invention to provide an integrated vehicle dispatch system that per~orms the management, coordination and communications functions for di~patching vehicles. The system consists o~ specialized software combined with a micro-computer network and graphic~ terminals where vehicle operators, dispatchers and customers are able to efficiently schedule deliveries.

Another ob;ect of the present invention is to provide ~or a vehiole dispatch system that assignR the most appropriate vehicle to a given event.

It is an additional object o~ th~ pr~sent invention to provide a vehicle di~patch sy~t~m that dete~mines the vehicle assignments bàsed upon a set of individually weighted factors.
The factors include the response time of the vehicle to the pick-up, the delivery time of th~ vehicle and the ability of the vehicle to handle the load weight of the proposed delivery.

It is yet a further object oP the present invention to provide a searching capability ~or searching transactions, addresses and accounts where information from the searches is auto~atically provided to the order entry program. It is still an additional ob;ect of this inventivn for the address searching capability to receive 911 emergency inPormation and then to automatically fill in the missing address data and geo-coordinates from the 911 in~ormation lnput.

. .
,.
. .
.
. ...
'.: ' ., ~ , ~(3~

It is ye~ another object of this invention to provide a rolodex routine, such that a user can automatically receive information most closely related to that ~earch by the address, account or transaction searching capabilities~

It iB still a ~urther ob~ect o~ thl inventian ~o provide a posting function which enables a user to flush out and post all of the transactions for today, tomorrow, and for reservations of dates previously established.

It is still an additional object of the present invention to provide a ~ystem status management module which enables the operator to optimize his ~source deployment to fit historical demand patterns and to identi~y resource po~ts de~ined by civic addre~s. Each of the post~ are then manned by a number of candidate vehicles based upon the speci~ic day~ and hours. The vehicles chosen for each post depend upon selected equip~ent characteristics and on-board personnel qualification~.

It is ye~ another object o the present invention to coordinate address searching with a geographic regions or geo-based file, such that addresses associated with an event are automatically searched, geo-located and displayed in conjunction with events on a cartographic video representation o~ the geo-based file (electronic map).

It is still an additional ob~ect of th~s invention ~o search transaction~ sequentially, such that, i~ a ~ransaction is not found under a current date, a pop-up calendar is activated in ~ ~

?~

order to enable a user to choo~e previous dates for transactiontracing~

It is still a further object of the present invention to provide a pricing program, such that all the prices can be automatically generated for each ordered transaction.

It is yet an additional ob~ect o~ thQ present invention to provide for a management monitor display which provides the user of the program with a snapshot of key operational statistics for a given period of time.

It is still a further object of this invention to provide fQr a graphic map display which includes a scope ~ode allowing a user to zoom, changing map scale in an uncons rained Xashion over a particular area.

The hardware syste~ o~ the pres~nt system consists of order entry workstation~ connected via a network marketed as the "BIT~US" network manufactured by the Intel Corporation of California (hereinafter "BITBUS") to one or more dispatcher workstations. The network is fully redundant such that each input in one micro-computer is stored in the memories of all microcomputers in the system. Each o~ the dispatcher workstations include microcomputer~ which control tex~ and color graphics monitors. A mobile digital data device i~ connected both to ~he dispatch worksta~ions and ~o a radio transceiver. The mobile device supplies information to a tran~ceiver on board the : .:

: . .: . .
~ , . .

~r~

vehicles. That information is then processed by vehicle-based microcomputers.

~ he on-board vehicle hardware may include an automated vehicle locator system based on the LORAN ~C~i coordinate navigation system. The LORAN transceiver signals the approximate real time vehicle position to the dispatch work station via a digital radio, automatically updating the actual position of the vehicles on the graphic display monitor. The vehicle information is displayed in the form of coordinate maps of the service areas.
The maps display icon-based indicatoræ of vehicle locations and downstream itineraries, pick-up and delivery locations, service zones and highlighted dis~lays o~ vehicl~ routes.

Tha software of the delivery system is organized into three main programs supported by numerous subroutines and functions. Th~ order entry program enable~ files to be automatically set up based upon different inpu~ types. Hence, through the use o~ past tran~action, address or account seeking techniques, incoming r~quests can be filled in automatically rather than requiring the caller to "spell out" every detail.

Th~ second main program is known a~ the dispatcher. This program allows for the selection of candidate vehicles based upon pre-selected criteria. In additio~, this program assigns routes to selected vehicles, calculates the minimum path travel times for those routes and monitors the succe~s~ul completion of pick-ups and deliveries.

_ 9 _ , The third program is known as the mobile digital data system (MDDS) program. This program controls the flow of communication between the dispatcher and the drivers in a mobile environment. This program per~orms the ~unction o~ receiving and storiny all data transmissions originating ~rom multiple dispatcher workstations and co~municating the transmissions with multiple vehicles. The map~ ~acilitate dispatch communications by calculatins downstream itinerarie~ based upon insertions/deletions made by the dispatcher.

- .. .
::
, 2~

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. lA is a schematic block diagram o the hardware of the order entry and dispatch workstations which form the present invention;

FIG. lB is a ~chematic block diagram showing the mobile unit of the present invQntion;

FIG. 2 is a flow chart representing the order entry program employed in the hardware of FIG. lA;

. FIG. 3 is a flo~ chart of the dispatch program employed in the hardware of FIG. lA;

FIG. 4 is a ~low chart of the mobile digital di~play program employed in the hardware o~ FIG. lA;

FIG. S is a flow chart of the accounting pro~ram employed in the hardware of FI~. lA, and FIG. 6 is a flow ahart of the insurance claim program employed in the hardware of FIG. lA.

.

' ~(~631,~8 ~

DETAILED DESCRIPTION OF THE INVEN~ION

I. The Hardware Referring to the figures wherein like reference numerals refer to like parts, FIGS. lA and lB illustra~e ~he hardware system of the present invention. The system uses micro-computer-based devices which togeth~r form an inherently redundant network.
The microcomputers are fully ~S-DOS compatible, have open architecture programming and are inter~aceable with popular dBASE
software products. Other data base and other software products in the ~S-DOS operating environment can al~o be used. The ~ystem hardware design supports all automatic veh~cl~ locator (AVL) product~ a~ well a~ all mobile digital terminal~ and bio-~elemetry device~. All hardware in the sy8te~ i8 used daily and can handle any task from inc~dent taking to dispatchinq.

By networking microcomputers together using "BITBU5"
technology, a multiple redundant network is achieved. Each machine in this network carries in its memory every transaction made by any sin~le unit in the system (when a transaction, accident report or field thereof is entered on ~ny of the machine , all of the machines in the system receive and store the information). Thus, if one computer ~ails, the system continues w~th no performance or data lo~. AB a result, expensive backup computers ar~ not necessa~y.

"

, . ..
.

Turning now to FIGo lA, the workstation configuration 10 is illustrated~ More particularly, two workstations are shown:
An order entry workstation 20 and a dispatch workstation 50. Each of the workstations are connected by a "BITBUS" 24.

A. The Order ~ntry Work~tatio~

The order entry work-station 20 shown in FIG. la consists of two order entry computers 12, 12 which are adapted to r~ceive incident information. This information i5 supplied to the computers via an RS-232C communications port ~, 8 through Hayes compatible modems 6, 6 connected to telephones 4, 4 . Each of the telephones is in turn connected to outgoing and incoming transaction lines 2, 2 .

Each of the computer~ 12, 12 , include~ a color monitor 14, 14 controlled by a color graphics adapter card placed in the computer cabinet 16, 16 . The types of computers used in th~
workstation 20 may preferably be a PC-XT, AT or any other IBM
compatible PC. The computer memory includes 640 kilobytes of RAM
and a 20 megabyte hard disk with a 28 ms. average access time. In addition, the computex includes a multi-function I/O controller card for controlling the RS-232C port as well as an internal real-time clockO

The hard disk contains suf~icient storage space for approximately 60,000 transactions. OP cours~, a larger size storage medium, sized to meet the user'~ transaction level, could also be used. This figure may vary according to the size of the .: , ~. .
,. , : , ~Q~
database install~d (geographic, graphic fil~, customer account information, e~c.)O The system has a built in feature such that whenever it detec~s at wake-up that a workstation has less than three megabytes of remaining ~ree storage space, it will automatically cancel the session until the operator has cleared a sufficient amount o~ space (using, ~or example, DOS copy and DEL
commands to clear previous weeks files and archive them on tape).
Thus, with the added redundancy of storing all featur~s of all transactions in all of th~ workstations me~ories, the system retains records that are fail-safe from power loss or e~uipment failure.

The computers 12 ~nd 12 are connected to one another via a "BITBUS" 220 The 'tBITBUS" is controlled by Intel 3051-based controller~ 18, 18 . They are also connected to the dispatch stations 52, 54 and the MDDS 56. A "BI~US" 24, in turn, connects the order entry stations 12 and 12 to the dispatch workstation 50. The "BITBUS" cabling i-~ shown as elements 22, 56 and 60 in FIG. lA.

~ . The Dispatch Workstation Tha dispatch workstation 50 consists of at least one microcomputer. In the present embodiment, two microcomputers 61, 61 ar~ shown. Each of those microcomputers includ~s a color text monitor screen 62, 62 and color graphic~ monitor screen 66, 66 .
The color ~onitors are respectively 12 inches and 19 inches in diameter. The 19 inch monitors 66, 66 are controlled by a professional graphics controller card, such as the PG 1280 or 1281 . - , .

cards manufactured by the Matrox Corp. of Montreal, Canada. As such, the monitor~ provide a high-speed parallel graphics capability to the workstation. Both the text and graphics screens are controlled by computers 61, 61 . The types of computers that may prefera~ly b~ used are those compatibl2 with the an Inkel 80386 based compatible microcomputer having an Intel 803~7 math co-processor. The memory for the microcomputers includes 640 kilobytes of RAM and 40 megabytes of hard disk. Moreover, each computer includes a 2 megabyte RAM extended memory card, a multi-function I/O controller card, and ~raphics adaptor cards, as described above.

In use, a dispatch~r uses a pre-programmed function ksyboard 65, 65 i~ order to route unit~, view transactions on the text screens 62, 62 , display information on individual units, assign unit~, accept con~ir~ations ~rom drivers, change assignments, con~irm units, ~oom-in on specific geographic locations on the graphic screens 66, 66 , and position trip locations.

Each of the dispatch microcomputers 61, 61 are connected via "BITBUS'~ 58 through a "BITBUS" d-DCM 800 ''BITBUS/PC'I trademark of DATE~, Ltd. of Ottawa, Canada interface controller 52, 54 and an MS/DOS intarfacQ located i~side the microcomputers.
Information communicated on the "BITBUS" includ~s redundant transaction data and polled AVL in~ormation. The AVL data consists of coordinates repre~enting each vehicle's real time location as the vehicle travel through a ~treet network. A
software module in microcomputer 61, 61 provides an interface ~or - lS -;~f~ r-~3~
the AVL signal. The module provides coordinates based on the coordinates provided by the AVL~ The vehicle coordinate information i~ then error-corrected in software to update the vehicle's position on the graphic display. Each o~ the dispatch work~tations also provides output $nformation via the "BITBUS" 60 to a mobile digital dispatch system (MDDS) unit 75.

C. The MDDS Hardware The MDDS unit uses a "RITBUS" controller 56. Th~
controller 56 is connected to a microcomputer 70 which can either be a PÇ-XT, AT or compatible device or an 80-386-based compa~ible microcomputer device. The MDDS microcomputer 70 includes an RS-232 port and interface card, a real time clock, a multi-function I/O controller card, and a hard disk. The hard disk stores 20 megabytes of data and the RA~ stores 640 kilobytes.
Finally, th~ microcomputer includes a 12 inch monochrom~ monitor 71 for displaying the status o~ the digital radio communications.

The microcomputer 70 is connected via an RS-232 serial-channel 72 to a modem 74. The modem is compatible with a radio transceiver 76. The radio transceiver 76 device operates at a minimum o~ 2400 baud.

In operation, the modem 74 modulates and demodulates all data passing ~etween th~ computer 70 and the mobile units 110 (see FIG. lB). This link uses a carrier dQtect protocol fvrmat allowing both voice and data transmissions to occur simultaneously, on the same ~reque~cy, using the same hardware.

~ ~ L ' ~ . ' : ~. ' ' ' ' ' ' ' ':

Z!~
The transceiver 76 can be hard-wired to the modem 7~, and the microcomputer 70 or it can be a separate data-radio transceiver which is ~upplied a~ one integral unit. Examples of such tranceivers include the device marketed under the name "DATARADIO"
by Dataradio Corp. of ~ontreal, Canada (hereina~ter 'tDATARADI0").

In situations requiring especially high performance or where radio communications on existing frequsncies ar~
problematic, a transceiver 76 can be specially built for data transmission at 4800 baud or above. These special transceivers can also use fast tur~ on delays and allow for less data packet collisions. The result of such an arrangement i~ clear digital radio-communications under the most adverse conditions.

The dispatcher system ~ully supports the use o~
microcomputer~ in the ambulance. Digital communications can be installed inexpensively using existing voice-radio a~ a transmission medium. The addition the "DATAkADIO" modem and microcomputer both at the dispatch center and in the vehicle can provide all the benefits of digital radio communication. By using such a "DATARADIO", all information stored in the system (page and files, vehicle routing, ~illing in~ormation, etc.) can thus be sent to a vehicl~.

The dispatch o~ signals i~ controlled by the network controller 70 which listen~ in and ~nd~ messages b~tween vehicles and the dispatch wcrkstation in much the sama manner as a telephone swi~chboard. A~ a resul~, bio~eleme~ry information (including a 12 lead ECG signal) can be sent in a matter of .
.

~n~
seconds from the patient's side in the ambulance or ~ehicle to a hospital~

D. The Mobile Unit FIG. lB illustra~e3 the mobile unit 100 moun~ed on a display vehicle 110 that i3 adapted to communlcate with the radio 76 o~ the dispatcher 50. The mobile digital communications unit 100 consists of an antenna 102 connected to a radio transceiver 104. The radio is hard-wired to a modem unit 106 which i5 connected by an RS-232C channel to a CP~ or DOS-based portable microcomputer 108.

The microcomputer-108 includes a serial communications port and an ~CD monitor screen (not hown). The m$crocsmputer 108 can include a Z-80 or HD 64180 type ~icrocomputer operating under a CP/M, MS-DOS or Z- WS operating system (with extended functions for s~rial I/0, time and power). The microcomputer also includes a nonvolatile RA~ disk~

The terminal 108 employs a display of su~ficient size to allow the driver to review a large amount of detailed information in a single call. It is pre~erred that the minimu~ screen size for the ~icrocomputer 108 will be an 8 x 4a or 16 x 16 display.
The type of LCD will preferably b~ a back-lit twisted LCD screen.

The microcomputer 108 also include~ an internal battery power unit having fail ~are automatic ~hutdown and RAM-save facilities. The so~tware include~ powQr con~rol func~ions for the syste~ and the computer may preferably be case-hardened such tha~

1~ --,. , . : :
,~ .. . . .
: . .~, , :. . .
~, , -. - . , it can withstand temperature extremes, spills, and shock vibrations from accidental drop~ or driver abuse.

An example of the type o~ computer meeting all of the above requirements is the computer marketed a~ the "MICROSCRIBE"
from the United Kingdom. The salient features of the "MICROSCRIBE" are an HD 64 manufactured by ~otorola or a Z-80 processor manufactured by Zilog, a CP/M or a DOS operaking system, a nonvolatile RAM disk, an 8 x 40 back-lit twisted LCD display and water resistant casing.

II. The Database Although the data~ase for the dispatch vehicle system is not shown i~ the figures, a description o~ its composition and method of creation are important to an understanding of the invention. In the Dispatch system, the database i5 defined as a logical sequence o~ stored in~ormation consisting of streets, place names, and any other features ~hat are relevan~ to a city network. In the order entry program 200, the stored information is called a geographical database. In the dispatch program 300, the stored information i5 called the topological database. Each of these database~ are set forth in more detail below.

Tha geographical database allow~ street, place names and other features to be associated with geographical coordinates.
The geographical database contains metropolitan network data such as street names and corresponding civic numbers a~ well as regional network data such as town names and cities. Depending on the application of the syst~m, the metropolitan and regional databases are di~erent and Xept separate in an application but their structure~ are equivalent.

The geographical database in composed of three files: the Streets file~ the Civic~ file and the Munic file. Using the three files mentioned above, the street file linX~ the other two files together.

The STREET file contains information such as street names, type, direction, and any ~eatures corresponding to the street name, including the municipality in which the streat i5 located.
The Civic file contains all the civic numbers (~treet address numbers~ and corresponding geographical ~oordinates ~or each intersection in the network. Th2 ~unic ~ile i a lookup table which contains unique codes for each municipality name in the metropolitan area.

The combination of ~he three files is used ex~ensi~ely by the order ~ntry program 200, allowing ~or rapid origin and destination location determination in the metropolitan network.
The structure o~ the geographical data~ase is designed to simplify and eliminat~ all possible overhead in searching and locating specific point~ within the boundaries of the metropolitan area.

Wherever pos~ible, numerical data (municipality codes, civic number~, coordinates) arQ compressed to binary ~ormat to maximize the speed and scope o~ acc~s to metropolitan geographical data on any single PC-type work station. ~his i~

... . . ' :

:
`
.~ . , ' ~ ` .

shown in the use o~ the Rolodex program 218 in the order entrymodule in which, if a street is mlsspelled, the user can verify and select the street name belonging to the municipality where his client is located (to be further discussed). The program can be described as a street guide that can be read without having to look at a map to ~ind the exact location o~ the client's address.

The geographical databa~e is created in a three step process. The first step involves digitizing the data. That step involves passing high quality maps through an interactive digitizing system. AR a result, the step identifies the coordinates of each intersection automatically and enables input of the relevant informati~n for each street segment (link). The resultant file will be referenced as PILB I.

In ths s~cond step, th~ file8 ar~ converted into a format where all information pertaining to each ~treet segment is isolated within each file record. That has been done to isolate all data pertaining to each str~et segment so that future editing such as addition, deletion or modification of street segments can be accomplished using the same digitizing system. The r~sultant file will be referenced as FI$~ II. A file of this type is available ~or ~ost metropolitan areas in Canada and the U.S. from, for exampl~, The Census Bureau, and is ref~rred to as a G8F File or "DI~E F1le".
The third ~tep convert~ FI~ II into two files: The STREETS.XXX and CIVICS.XXX files. Those files will be referenced as FILæ III, The ~treets file is an ASCII-~orted sequence of ~)6)~S~3~

uniquely named street segments within a specific municipal corporation containing pointers to the coordinates and civic numbers in the Civic file. The Streets file also contains a final byte called a continUQ code indicating whe~her the previous record contains the sam~ ASCII string (street name and type), which allow~ for faster search and more as~i~tance to the operator in identifying po~sible ambiguitias where treets extend through several municipalities or where multiple occurrences of the same street name in different sectors of a metropolitan area exist.

The geographical databaso also has another usage. Since it contains all street segments within a metropolitan area, it is used a~ the basis for the ~ap image in the dispatch program 3~0.

The front ima~es on the graphic~ screen~ 66, 66 are created from FILE II. Since the FILB II contains in each record all the information relevant to each streat segment for the metropolitan area, the actual drawing of each street se~ment is simply moved to a first point of the segment and drawn to a second point of the se~ment. This is dons for each street segment from the file.

As the segments are drawn, they are recorded as vectors in a vector file. The integrated vector or graphic "Meta" file for the entire metropolitan area allows for the graphic input cursor I~SCOpQI~ to create and "zoom" in on any window desired by the dispatch program usQr. Once the whole metropolitan area has been drawn, the whole image is stored in another file, in binary-pixel format. As a result, a display for the metropolitan image is ~ ~ ' ;' , - z~ s~

quiokly created pursuan~ to a "re~resh" command after a "zoom"
operation.

The topological da~abase is devaloped ~rom FIL~ II. It may or may not US2 all of the ~nformation irom FIL~ The topological database primarily consists o~ street segments or links, and their respective node numbers with X, Y coordinates.
Its main purpose i~ to route vehicles through the road network at dispatch time. The topological database is built to ensure complete "connectivity'~ throughout the road network so that the vehicle routing algorithms can always find a path from any point to any other point in the metropolitan area.

Part of the preparation process includes an automated procedure for "stripping" ths network ~metropolita~ or regional) of unnecessary roads. These ~tripped po~sible roads include dead ends, a sequence o~ links joined by only one node, and other extraneous street segment~ whose prssence would only increase the time required to find ~he minimum path, without necessarily improving the accuracy of the routing and tracking system.

Once created, the topological database consisks o~ ~our file ~ormats: the Link file, the Link Category ~ile, the Link Distance ~ile and the Node file.

The Link file con~ists og two node number~, which designate the link number.

' ' ' : , ~ .
- ' ~
.
' . .' ~ ~ . ~ ' The Link Category file defines the road classification o~
the links from the Link file. Expected travelling times alony each link are computed from knowledge o~ the road classification and the link distance.

The Link Distance file defines the distance for each link from th~ link file in units of mile~ or kilometersO

The Node file contains all in~ersectinns (nodes) which connect all links. This file also contains all coordinates that position the street intersections on the map.

III. ~he Software A. ~ae Order Entry Program As shown in FIG. 2, the order entry sy tem 200 primarily functions to automatically verify and locate each incident address, account or transaction that is received as input. All available information regarding a prior patient is automatically recalled and relayed to the dispatch program (see FIG. 3). Upon system installation, a complete rolodex file 218 of every address in every municipality within a given service area is entered. In addition, a complete listing of all street location "pointers'l to a graphic map display, accurate to the block level, i~ provided by the rolodex 218.

, - ; I .

Other on-line rolodex files instantly available to the order entry program include the patient rolodex, the subscription rolodex, tha place-name rolodex, the address rolodex and the account tracing ~iles. The order entry ~cr~en may b~ customized to each client's specifications to ensur~ an operational integrity and capture of all relevant data.

The order entry program 200 consist~ of three levels of external event processing~ the Xeyboard level 210, the serial input/output level 230 (SIO) and the "BITBUS" processing level 240. The subroutines of this program are described in more detail below in the context of each level of event processing.

1. The Keyboard Leyel The keyboard level 210 i~ programmed to activate a variety of function~ including the output of messages to the "BITBUS" 240 and tc the 5I0 230. The keyboard functions to both input and search fields. Data fields are accepted in alphanumeric format and are verified automatically on the system for integrity.
Information is stored in a transaction buffer 215 which is then flushed when a transaction is posted to the dispatch system or refiled when the transaction is recalled.

~ h~ keyboard level 210 utilizes three search routines:
the account search 212, the addresæ search 214 and the transaction search 216. Each of the searches i~ activated by the entry of data~ield~ which provides "key3" initiating such searchss. For example, in a me~rop~ an environ~ent, the address search .. ~ . .

:

znn~ ~

requires a minimum of one street name and either a cross street or a civic number. The address search 214 will, if successful, output the name of the municipality to th0 appropriate data field, to both the screen and internally to the tran~action bu~fer 215.

Each of those searche8 then acts to "~ill in" the in~ormation based upon what is input into the keyboard 210. A
successful search will fill in the appropriate data fields in the screen based upon an initial input. Any ~ubsequent entries on the keyboard 210 and will be automatically detected by the system as possible upda~es to the file and a system query for the desired update will be automatically handled. A more detailed description of the account addre~s and~transact~on search programs 212, 214 and 216 is provided below.

As previously discuss¢d, the rolodex subroutine 218 provides scrolled access on a separate video page to ordered files. The files can include account files, metropolitan street indexes, etc. The rolodex is opened at the closest location matching key which has been entered onto the keyboard 210. By selecting the rolod~x entry, the appropriate data ~ield on the screen i8 filled in and the internal ~iles are automatically updated.

The screen control subroutinc 224 provides a plurality of functions which arQ c4nvenient ~or cursor positioning and help ~creens. The scr~en control functions also will be described later in more detail.

:
.

. r-~3~

The posting function ~19 provides for flushing out of the transaction buffers 215 containing either current transactions or previously recalled transactions. options available in the posting subroutine include:

1. Post transactions for today;

2. Post transactions ~or t~morrow;

3. Post transactions ~or a speci~ic reservation date as previously established using the pop-up calendar in the transaction search; and 4. Any o~ the above in multipla form, e.g., same pickup for several inter-city transaction~.

The order ~ntry program also include~ a system status mana~ement (SSM) routine ~2~. The SS~ routine allow~ for the identification of resource post# which are defined by civic address. The SSM routine allows for th~ creation of flexible resource deployment plans ~or specified day~ of the week at specified hours. There are no system limits on the number of plans that can be developed and ~tored. The types of plans that can be used include specific di~aster evacuation plans, special event plan~ or routine pre scheduled work plans. The SS~ plans that are entered into thls system may include the following components:

1. Th~ nu~ber of post~ and their geographic locations;

2~

2. The numbers o~ vehicles required for each post; and 3. The types of vehicles required. The system imposes a two tier definitional requirement ~or the kind o~
vehicles required. This requirement will ~irst identify the vehicle equipment characteristics and then identify the on~board personne]., including their certification level~.

In operation, the plans are automatically loaded by the dispatch program (FIG. 3) with a predetermined lead time ~or the event. A message is then provided to the operator that th~ plan is imminent. The operator then has the ability to interactively assign resources to posts in accordance with the plan. This capability extends not only to the identlfication o~ resources in the service area~, but to those resources outside o~ the service areas.

The dispatch as~istant option 220 allow~ the order entry program 200 to look like a "dispatch" text screen with all o~ the text screen control features. These ~eatures will be described in more detail below with respect to FIG. 3.

Finally, the order entry program lncludes a video control program 242 which work~ in conjunct;on with a cursor screen control program 224. Both program~ 224 and 242 control the presentation o~ in~ormation, the movement of data on the screen and the interaction betwaen the keyboard and the screen. The - 2~ -. . ~. ,, , I , ;. .
. - : - . , , .~. " . :
. . ~

(~

operation of those programs also will be described in more detail below.

2. The SeriaL I/o Level Ths serial input/output (SI0) event proces~or program 230 i5 driven by interrupt~ from a s~rial communications controller (see FIG. lA). The SI0 is subject over telephone lines to standard error checking protocols between the sending and the transmitting stations. The 5I0 program 230 can receive incoming transactions posted on a remote order entry workstation communicating through a Hayes-compatible modem 6 (see FIG. lA).
The SI0 interrupt input is also adaptable ~or direct input of serial AS~II data using DTR/CTS handshaking. Accordingly, t~e proces~or can readily ~nter~ace with an ANI~LI controller for 911 serial communications. When 911 data is received by the SI0, it is automatically sent to the address search routine 214 where it is appended with exact address coordinates in the transaction buffer 215.

3. The "BITBUS" Level The "BITBUS" communications program 240 polls the d-DCM
800, 810 PC "BITBUS" interface units 18, 18 (see FIG. lA). The "BITBUS" ~o~tware is interrupt driven and ha~ it-~ own ~irmware-ba~ed oparating sy~tem. Although any operating syst~m can be u~ed, th~ pre~erable operating ~y~tem is ba~ed on the Intel RMX-51. ThQ operating system provides Por arror checking and retry procedures along the "BITBUS". Moreover, the "BITBUS"

~ - 29 . . .... , .:,:
.
.: . :

:. `

program 240 includes on board bu~fers which allow it to use 13 byte packet storage until the polling routine sends an acknowledgment o~ its receipt. These capabilities allow the microcomputers to serve both the keyboards and the ~erial board without the hazard o~ data loss on the "BITBU~" network~

4. Ope~tiQn of the~5s~ 89~

The various subroutines of the order entry program operate in the following manner. When the keyboard operator types in a delivery request on keyboaxd 210, the address subroutine 214 can then be activated by a function key once a minimum number of data field are received (the civic number and s~reet name). The search related field~ that require completion by the address search 214 include: civic number, street name, street type, street direction, municipality name and cross stre~t. Depending upon the ~treet naming conventions, th~ type and direction fields may not be required.

For emergency applications, however, where the civic address cannot be reported, entry of the cross street will cause the address search to find the confluence of the two streets and to report the results.

~ h~ addre~-~ search routine performs an ASCII binary search on the street name fil~ called "Streets .XXXI' (the triple X is the file name extension of the m~tropolitan are~, e.g., "MIA" for "~iamii'), If the name is found, then the file seek position is backed-up to the first occurrence of that name. Each street file .~ . , `

. .
.

entry includes a pointer to a larger file containing the civic address and the corresponding geo-coordinates, A second file is then searched for a civic address ma~ch ("CIVICS.XXX"). If a match is not found, the pointer from the next street file record is used and the process is then repeated. Thi~ continues until either the name changes in the street file or a civic address match is found.

If a street match is found, then the search proceidure provides the name o~ the "found" municipality on the display. If the street name is not found, the search procedure outputs a message to the screen that is the closest name found during the binary search. This "clos8" name will often alert an operator of possible spelling errors. Thereore, the closest street name algorithm will usually find the correct name.

If there i5 a mistake, the operator can then invoke the rolodex subroutine 218 which will display the street index entries with the full name, street type, stre~it direction and municipality. The rolodex program list will start with the closest name to that entered during thie address search routine 214. Using thi capability, the exact entry can then be chosen by the user. The selection will causa the name, type, direction and municipality field~ to be automatically filled. At this point, the program will return the user back to the address search program 214.

As previously mentioned, the address search program 214 can be invoked directly by the SI0 program 230. That scenario , ; , .

Z~ 5)~
would apply in the case of ANI/ALI (automatic number identification/automatic location identification) 911-controller input which usually provides an ASCII message containing the billing address corresponding to a given telephone number. When an end of message signal haæ been received by the SIO, the 911 address information i~ passed on to the addres~ search procedure 214 be~ore the 911 originating transaction is posted. In such a situation, a flag is set to bypass the interactive queries of the address search procedure 214. If the 911 search does not successfully find the geo-coordinates Por the 911 address, the record is flagged and a message is left flashing at the bottom of the operator's screen containing the transaction number. The operator can then recali the transaction in th~ manner described above to correct address error~ originating from the 911 transmission (or from the telephone company's database).

To ensure maximum performance from the address search program, the digital geo-based files are preprocessed for each metropolitan region and updated in the current year. The ordering o~ these files consists of sorting the record~ in descending priority by name, street type, street direztion, municipality and civic number. The civic addresses and geo-coordinates relating to a specific street are then collected and extracted in a sorted file. A STREETS file with entries ~or speci~ic names, types, directions and municipalitie~ is then created with pointers to the CIVICS ~ile.

The account search program 212 operates to fill in the appropriate data fields in the account category when a n w accoun~
or an old account i5 entered. In ~he case o~ an old account, the user enters a corporate or patient name. Once entered, the system will then search for a match of tha nam~ and provide that infor~ation on the screen. Should the information be corxect, then any subsequent keyboard entrie~ to the account will be detected by the system and a possible update of that account file will occur following a system query.

The transaction search program 216 operates when information in any of the fields is ntered. The system searches for the first occurrence ~ a transaction containing this field and that information can then be pro~pted to continue sequentially until the de~ired transaction is found. I~ a vehicle has already been assigned to the transaction, then the order entry screen will display four additional fields containing the time of the call, the call number Qf the vehicle as~igned ~o the job and the latest times o~ pickup and delivery as requested by the dispatch program as shown in FIG. 3.

The transaction search 216 is keyed in on any data fieldD
By default, the order entry software looks for the transaction under the current date. A pop-up calendar is then activated by the function key to choose previou~ date~ for trans~ction tracing.

A number oP field~ are provided on the screen during the order entry program. The chart below indicates the number of ' ., ' "' ' , ' ~~ ~nr~ s~
bytes and the fields associated with those bytes for the order entry scre~n:

FIELD NAMENUMB~OF BY~
Civic Number4 Street Nams20 Street Typ~ 2 Direction Code Municipality Code In addition, the order entry program can include an automatic pricing program (not shown). The pricing is based upon each user's specification using service codes and diætances as determinants. These specification~ are then entered using a program which determines (1) the ba~e rate, ~2) rate per additional mile, (3) additional charges, and (4) contractual adjustments. Prices are also modi~ied according to special rates applying to specific accounts. ~hese accounts and corresponding rates ara contained in a companion ~ile to the account file.

Finally, the order entxy program includes a management data display feature control program 242. The display is event driven and watches the transaction file f or any events recorded therein. In use, a default screen on the manager's processor appears when that screen is not be~ng used ~or any other purpose.
The event~ chosen present the manager with a snapshot of the key statisticsi o~ the day's operations. A sample screen from the management data display is shown below:

- 3~ -. ' . . .
', ' OPERATION'S MONITOR
~eneral Statistics ~ispatch Statistics Number of Jobs.XX Undispatched Jobs.XX
Tomorrow Job~.XX Completed Jobs.XX
Prescheduled Jobs.XX on Time Completions~XX
Preloaded Jobs.XX Time ~o Pickup.XX
Loaded Jobs.XX Time to Completion.XX
Modified JobsOXX
Deleted Jobs.XX

S~A~ISTIC~ BY ORDER ~NT~Y S~TION
Calls ~rocessed Calls_Mod~ Time ~ Entry Typo Entry B. The DisPatch Pro~ram A flow chart for the dispatcher program is shown in FIG.
3. The dispatcher program performs a nu~ber of functions including routing units, displaying daily transactions, displaying candidate units, as~igning units to jobs, accepting confirmations of d~liveries from drivers, changing routing assignmants, confirming unit performances, zooming in on specific geographic locations, positioning trip locations and determining minimum travel paths.

, z(~r~

The dispatch program has several levels of events which are to be serviced. Two of the e~ents are external. Of the other five, four ara driven by a real-time clock program 326. The events include keyboard 302, "BITBUS~' input 320, vehicle position change 32~, stop confirmation buffer increment 324, and the real-time clock events. Real-time clock events include (pre-scheduled job deadlines 326, emergency transaction deadlines 326 and date change verification 32~.3 Each of the event levels and subroutines of the dispatcher program 300 i5 described below.

1. ~he Keyboard Event The keyboard program 302 provides the graphic and text screen control functions 304, 306 respectively. In addition, the keyboard program 302 controls activation of a variety of xoutines which include vehicle candidate ~election 308, v~hicle assignment 310 and routing and stop confirmations 304O

In operation, the function keys of the keyboard program 302 activate, for example, the loading of appropriate segme~ts of the transaction file which are then transferred to a video bu~fer.
The various function key~ and tab keys on the keyboard also cause the transaction file to be re-mapped to a video buffer for display of the appropriate part of each transaction. As such, pickup information, delivery information and vehicle assignments all can be separately shown once the keyboard function~ are pressed.
The function keys are totally configurable by the type of application environment and can b~ defined in a dispatch query - 3~ --~ ~s~

menu at the beginning of the program. A detailed description of each function key will be described in more detail below.

2. Gra~hic Cursor Control a~d Text Screen Control The Graphic Cursor Control program operates through keyboard 302 in two mode~: a map modQ and a scope mode.

The map mode is the default mode. In the map mode, the graphic display 66 (FIG. 1) reveals a map of the entire urban area served. Superimposed upon the map are the following features:

a. When a transaction is highlighted by the cursor on the text screen, 62, 62 the yraphic display 66, 66 reveals a red "Up" arrow that marks the precise pickup location and a red "Down"
arrow~that marks the precise delivery location.

b. When a "Candidake Vehicle" key i~ pres~ed, the display instantly present~ up to three vehicle~. The vehicles are displayed in order of sy~tem pre~erence by color (sae discussion below regarding candidate selection 308). The call number of the vehicle then appears in a rectangle at its current estimated position and the down stream itinerary is displayed with all of the ~tops u~ing different icons for pickup~ and for delivery (square for pickup, circle for delivery). Icons are also used for any pre~scheduled non-emergency calls.

- ' , ' ~' .; ;' : . ' ` !
`' ` , ' ~` ~ ` ` : :`
, ~
'`'~ ', ' ''~' ;`
~, , .

~q~

c. When the vehicle number is assigned, a new itinerary for the vehicle is displayed showing its current location. In addition, th~ computer displays each pickup and each delivery assigned to that vehicle and each assignment yet to be completed.

The scope mode is entered ~rom the map mode. The scope mode is activated by a function key toggle (thus, disabling the "Text Screen Control" key). The choice of this mode will cause a window having a central cro~s-hair to be dispatched. This window or scope i movable to any position on the map. It can be expanded or contracted to establ$~h a zoom window. Prior to entering the ~cope mode, however, the dispatcher will select a particular area of the ma~ to zoom in. This zoom i8 accomplished ~y using arrow keys to position the reotangular scope box. Zoom degree is controlled by the 'IPag~ Up" and "Page Down" keys which increase or decrease thQ size of th~ scopa box.

Th~ scop~ feature provides a blowup o~ the area map selected by the scope (in ot~er word~, a zoom in on the area within the scope). At larger scales the zoom will reveal the street names which are displayed and aligned with the street direction.

Th~ scope feature, in combination with the zoom program, provides a number of ~unctions, including the ~ollowing:

a. The scope creates an easily ~ollowed vehicle route;

b. The ~cope can loca~e a non-fixed hand-off point;

:

, c~ The scope can locate an insertion point or points for pickup and delivery; and d. The scope can position a vehicle ak a post location.

The zoom is activated by a ~unction key and loads an appropriate ~egment of the memory. The memory then writes information sequentially into a graphics controller buffer.

A refresh function key also is provided which reloads the main map from which the scope i~ taken. The main map thus forms a separate file which is pr~processed in a blt-map pixel-by-pixel format. The map can be easily retrieved Prom th2 extended ("protected") memory area~of the microcomputer, u~ing a 386 alOS
interrupt ~or protected memoryO

All o~ the operat~on area maps are preproce sed using digital geo-based files (e.g., U~S. Censu~ ~ureau GBF/DI~E files, statistics ~iles~ etc.~. The maps are accessed by software in the ~orm of two files created by the preprocessor. The ~irst file sequences the graphic commands compatibls with the graphics controller in a META-file format. The latter file comprises a numibar of pointers into which a zoom can load only those necessary portions of the file ~or zooming window control.

3. Candidate Selection ~o~

The candidate selec~ion program 308 acts to identify the best candidate vehicles to be used for a given transaction. When the user decide~ to a~sign the current job to a candidate vehicle, ~ - 39 -,, , ,~

, .

, he presses a key which activates a candidate search algorithm 308.
The algorithm identifies the best three candidates for a current transaction. The candidates are determined in accordance with penalty points or a "weight" value assigned to each vehicle based upon th~ following criteria:

a. Distance Out of the Way: The total addikional distance travelled if the new stop is to be inserted, or if the new stop i~ to be reached directly from the vehicle's current location. A user defined scaling factor is applied to the straight line distance. Points are assigned for each mile and minute of additional travel.

b~ Estimated Time o~ Arrival: This estimated time i-calculated and the estimated times o~ all the downstream stops are added together. The points are ad~u ted for every minute late at the new stop. The estimated time~ are adjusted based on the actual travel time for each element of the trip, i.e., the time to pickup, time to deliv~ry, time to clear, etc;

c. Vehicle Profile: The vehicle's profile is defined by the weight and volume capacity of the vehicle based upon the following factors:
(1) For emergency applications the current status is used to reject a vehicle if it is in service.

. (2) The vehicle category must match the service type codes entered in the order entry program 200.

, .

~n~
(3) If th~ weight or volume is a consideration for the transaction, the vehicle's ca~acity is checked both at the ne~J
stop and at each subsequent stop a~er calculating an expected weight for all of the stops. The calculation is ba~ed upon the vehicle load profile given the anticipated volume and weight for each pickup. Penalty points are as igned for excess loads at the new stops and at the downstream stops.

The actual search algorithm then is performed in the following steps:

Step 1. Pick a vehicle that has not been assigned.

Step 2. Calcula~e penalty points ~or insertion of the pickup stop.

Step 3. Calculate penalty points fro~ th~ first unchecked stop down~tream and from the vehicle's current position.

Step 4. If the point tally in step 3 is less than the previous point tally, mark the stop.

Step S. Repeat steps 3 through 5 until all stops have been checked.

Step 6. Repeat steps 2 through 6 for the delivery stop.

Step 7. If the lowest number o~ points for a marked stop is less than the lowest tally for all previous vehicles checked, mark the vehicle.

5~q Step 8. Repeat steps 1 through 7 for all vehicles in the fleet.

Step g. Choose the best three candidates according to the lowest point tally for each vehicle.

The criteria can also be weighted to mee~ the sp~cial requirements of the transaction. By as~igning zero points to a category, ~or example, the dispatcher can e~ectively ignore a constraint. There is also a point rsduction factor available for vehicles that are on standby. Since the distance out of the way criteria is high for such vehicles d the user can use this option ~or reducing the number o~ ef~iciency points ~or such vehicles.

The best candidate vehicles will be displayed in the darke~t color. Once selected by the user, the vehicle appears as a user defined icon at its current position on the graphic screen.
The itin~rary of the vehicle is displayed on text screen in the same color.

4. Vehicle Assi~nment Once a vehicle selection call number has been determined by the candidate selection program 308 or entered by the keyboard 302, th~ vehicle assignment program 310 is used. The assignment routine si~ply determine the optimal insertion point ~or a pickup and for a delivery in the selected vehicle's itinerary. Each of the pickup and delivery polnts are then displayed on the graphic screen.

.

: , . ' ` ' ' z~

A dispatcher has the option to override an insertion point and can shift through itineraries until he finds his choice. The vehicle is then assigned to a transaction by entering its three digit call number into the "VEH Position" box o~ the vehic]e assignment window. The system usually then requires an average o~
ten seconds to determine the travel path through the street network of the i~inerary, causing a blinking message "Routing" to be displayed.

The system will also warn the dispatcher when an assignment causes any other job to be violated. The system then identifies that job in jeopardy. Thus, if a new stop is inserted into a prescheduled route d~using the addition~l stop to make the estimated time of delivery late, the system will warn the dispatcher that there is not enough time ~or the previous job.
The dispatcher may then override the time window for the previously assigned stop or cancel the new vehicle assignment.

5~ Minimum Path Calculation The assignment program 310 operates in close conjunction ~ith the minimum path subroutine 3~2. The minimum path program determines the minimum travel time by accessing a road network information base through the expanded memory manager (EMM) software. An expanded memory manager according to the Lotus-Intel-Microsoft standard 4.0 may be utilized.

The minimu~ path calculation is used to estimate the road and network travel path and to time every new vehicle itinerary "
.~. . . .
, that is created by the dispatcher's decision. The minimum path algorithm employs the concept of directional network links ordered by ascend~ng nod~ numb~r~. The original in~ormation ~or the nodes and links is obtained from a geo-database and i9 updated by a separate digitiæing program. The nodes are organized such that the starting and ending nodes of a link represent the street and network intersections. I~ the street segment between the links is bidirectional, then ~wo link are used. The network arrays consist of the following information:

A = Starting Node The A Node Number B = Ending Node The B Node Number Th~ Link Distance The Road Category The sequencing of link~ by increasing "A" and then increasing "B" numbers. Travel tim2s for each link are determined as a function of the link distance and the road category. The travel times are loaded along with the node number arrays into "expanded memory" at run-time. The times for each link are then automatically adjusted durinq different hours of the day. As such, traf~ic conditions can be factored into time determinations.
The syste~ also has the capability of allowing ~or graphics input to specify changes in road links based upon unpredicted or unusual traffic conditions, such as accidents, road repair~, police block~, etc.

- 4~ -' The algorithm uses a minimum path tre0 program starting at a known origin and extending outwaxd to every other node that is in that networX. A path to any one o~ the nodes in the origin is called a branch. There are multiple branches ext~nding from a given node. Finding a minimum path to a destination consists o~
the following ~teps:

Step 1. Initialize in an lnternal array the total travel time of all the branches.

Step 2. Find all the "B'~ Nodes connected to an "A" Node on the ~irst iteration.
5tep 3. For eac~ new "B" node, add the link timo from the "A'~ node to ~he travel time on that "A" node.
The re~ult b~ng th~ branch time for the current "B" node.
Step 4. Retain the branch travel time in a separate array. If th~ branch travel time is les~ than the existing total travel time determined by step 1, replac~ the existing total time with the new branch time. In another internal array, the "Al' node value is stored which was used to reach the branch time in step 3.
StQP 5. For all ~B~l nodes whose travel time i~ less than the total time retained in Step 4, repeat the iteration of Steps 2 through 4.
If at any point in this process the destination ~ode is reached, then reject all o~ the "B" nodes for which the branch travel time i~ greater than the branch time to that destination.
Step 6. Repeat Step 5 untll the internal array oP "B" node~ is empty.

.:: : . . .
' '` : I ` ` , ' ' i , ~' , ~ ' " ` ' '.

i ` ' ` ' .

- zn~

Step 7. Retrace the path ~rom the destination to the origin using the array "A" node value stored in Step 4.
The algorithm operates on an average o~ about one second per 10,000 links. With expanded memory, the road link network feature can operate in any size metropolitan area. However, to save on memory space, the small inconsequential road map links . having negligible impact on travel time may ~e removed. The removal of these link~ in the road network while maintaining all of the topological connectivity ~eatures o~ the network is carried by a batch preproces~ing technigye used in the present system.

The algorithm executes at the same time that the "BITBUS"
unit 320 polls the network. In addition, polling of the keyboard permits the di3patcher to view other text window~ while the algorithm is ex~cuting.

Once the minimum path algorith~ is calculated, the vehicle itinerary ~ile is updated and time stamp~ are placed on the transaction showing estimated time of pickup and estimated time of deliveries. The travel times are then displayed on the screens.

60 The Confirmation Pro~ra~

Th~ confirmations subroutine 314 interacts with the minimum path program 312 and assignment program 310 to flag acknowledgment of assignment~ by a vehicle or report various pickup, arrival and departure completion~. When receiving confir~ation~, the estimated time o~ pickup and estimated time of departure described above are adjusted to effect the downstream ~' , ' '`''`''~ ' .

vehicle itinerary. All of the assignment confirmation flags are scheduled automatically by the system in the minimum path alyorithm and also are sent via the "BITBUS" to the order entry and MDDS program (see FIG. 4).

Confirmations o~ assignments ar~ represented on the screen by letters beneath a check mark headed column. There are four check marks on the screen, each indicating different confirmation points. The first chesk mark indicates the vehicle's arrival at the pickup location. When a confirmation is received, the letter "P" is entered under this check mark. The second check mark represents leaving the pickup location and is represented by the l~tter "L" when confirmed~ The third check mark represents a confirmation of arrival at the de3tination point and is representad by the letter "D'~ when confirmed. Finally, the fo~rth check mark confirm the departure from the destination location and is repre~ented by the letter "C~ ~or "Clear".

: . .
.

()~

The appearance o~ the con~irmation soreen i9 shown below:

Vh V~ ec. Inst~uction~ ~OC _ ~0~ _ETP ETL ETD ETC T
128 PLDC USE BACK DOOR 13:43 13:44 13:54 14:05 14:15 14:30 . .14:01 312 P 14:03 14:05 14:13 14:20 422 PL 14:03 14:04 14:20 14:35 14:45 14:04 DIA~ETIC 14:15 _ _ .
Tuesday May 3, 1988 ~ 5/6 Connect 14:31-47 7. The "BITBUS'1 Con~ir~tion, Vehicle Position and Real-~i~e Clock ~oqra~

The "BITBUS" routine 320 is similar to that described above with reference to FIG. 2. In other words, the software 32 provides error checking, handshaking and polling functions. All "8ITBUS" infor~ation is provided to either the text control or con~irmation screens and ha~ the hiyhest priority of the external event functions in the d~spatch program 300.

The get vehicle po~ition change program 322 is activated throughout the vehicl~ itinerary. T~i~ program update~ the vehicle's position in the network and on the screen.

.. . . .

.

The stop confirmation buffer 324 i5 filled by the "BIT8US"
messages either from the dispatch system program 220 or the MDDS
Software (FIG. 4). The confirmation routine 314 routinely checks the stop confirmation buffer 324 and then incrementally process~s the nex~ outstanding confirmation. Data ~rom the confirmation buffer is regularly polled by the con~lr~ation routine 314.

The real-time clock procedure operations are as follows:
Pre-scheduled jobs are entered into a permanent file with specific days of the week. The system then automatically loads the appropriate jobs each day into a daily transactio~ queue. As a result, the pre-scheduled jobs can be added, deleted or modified up to a year in advance~ ~he pre-sch~duled transactions are created at the order entry stage (FIG. 2) and include time windows which will not be display~d on an undispatched job screen until a specific delay before a deadline (usually a hal~ hour). Thus, the real time clock subroutine 326 is polled at this level in order to determine whether any of the pre-schedules should become active on the text display. Once a half hour increment is reached, for example, the real time clock 326 causes a pre-scheduled reminder to be activated which is then provided to the text control routine 304.

All transactions that are entered by the order entry program in FIG. 2 a~ emergencies are automatically assigned deadlines. Emergency indicators are raised within a specified time period from the time that the call i9 stamped by the order entry program. Failing a pickup confirmation, ~or example, within such a specified deadline (as determined fxom polling to the real-time clock 326) will change the video attribute to a blinking message.

The real time clock affect~ th2 date change verification which occurs at the lowe t level o~ the event proce~sing. In use, the dispatch program 300 poll~ th~ real time clock 326 in order to detect a midnight transition to the next calendar day. Once the transition is detected, the operator is warned to activate a function key in order to close the current day's fil~s. The next day's files are then automatically opened and a warning is echoed on the "BITBUS" to all the other workstations to automatically close the previous day's ~iles and open the next day's files.

3. operation of the Dispatch Pro~ram When the unit is turned "ON" a daily transaction screen is displayed. The scr~en includes the names of the patients, facilities and their addresse-~. If none of these transactions have yet been dispatched, the operator can then proceed to assign a unit to that transaction. That i8 accomplished by pressing a function key bringing the user into the candidate selection proqram 308 described previously.

A u6er can then select a candidate vehicle by pressing a function key and positioning the cursor on the ~ield where the unit number can then be entered. Once a unit has bean assigned, an estimated time o~ arrival will be displayed. The routing occurs automatically and the screen will ~lash for a given number 3~ S~
of seconds allowing the system to perform the dispatching function.

In the event that it become~ necessary to assign additional trips to a given unit, the user then places the cursor over the unit ~field" o~ the transaction screen and enters that unit number. A red circle will then appear in the graphic screen around the unit. The system queries the user to confirm the next stop that they just entered. The user can then change the insertion point for the new stop by pre~sing the "+" key which will move the red circl~ to the n~xt stop downstream on the graphic screen.

once a driver calls in to con~irm tha~ an assignment ~as been clear~d, the confirmation~ program 314 can be accessed. The user can then entQr th~ con~irmation symbols as de cribed previously. A dispatched unit also can be unassigned by pressing a function key. The function will then automatically remove the pickup and destination requirements fro~ the computer itinerary.

The dispatch program includes a nu~ber of monitoring features which better facilitate the use of the system to best fit the cognitive processes that a dispatcher must use to effectively coordinate vehicle pick~ups and deliveries. One of those features is the dispatch query menu which allows an operator to view sQlected information from the daily transactions ileO That menu i8 configurable for dif~rent applications. The ambulance dispatch query menu appears as follows:

.
.

2()~ r~

_spatch ~uery Menu (1) Incomplete Trips (2) By unit no.
(3) Undispatched trips (4) By patient name (5) Cancelled trips ( 6 ) Al l tri ps (~ All trips by unit The various menu options in the dispatch query menu are accessed by pressing the number adjacent each query satego~y and then hitting ths "Return" key.

The option operate as ~ollows: Option No. 1 displays all of the trips which have not yet been cleared by the system by vehicla.unit number; Option No. 2 will ~irst prompt the user-to enter a unit number and then di~play all of the informatlon regardin~ the incomplete trip~ for this unit. The third option, "Undispatched Trips," displays all trips for which a unit has not yet been assigned; the ~ourth option will first prompt the user to enter the patient'~ name and then display all of the trip~, dispatched and undispatched, for that patient.

The cancelled trips option number 5 displays all trips which have been cancelled from an order entry workstation. option 6 allows the user to view all o~ the trips, whether dispatched or undispatched, confirmed or uncon~irmed. However, deleted trips will not be displayed. Finally, option number 7 will first prompt the user to enter the vehicl~ unit numbar and then display all of the trip~ for that particular unit. The trips are displayed .~ "

~: .
.
, : , . , ... :
- ~ " , , ; ~ `

~f)~

whether they have been dispatched or undispatched, confirmed or unconfirmed.

Another set of functions relate to control o~ the text soreen control program 302 and graphic cursor control program 306.
These keys can be classifit2d into di~ferent cateqories.

The arrow keys, for example, ar~ used to move the cursor around the text and graphic scre~ns without changing the content of data. The "Page Up" and "Page Down" keys are used to display different pages on the text screen and to increase or decrease the size o~ the scope on the graphic screen. The "Tab" Key is used to move through different ~ield~ for each trip.

The function keys (F1 through F10) p~rform specific functions which a~fect the content o~ data. A set o~ extra function keys is created by alternative use of the "ALT" or "SHIFT" keys in combination with the function keys.

The system is alway~ in one of two mode~, text mode or graphics mode. This is due to the fact that certain keys are used for two purposes. The effect of pressing those keys will thereby depend upon the current mode. To switch modes, a function key is pressed. If the system is in a graphics mode, the letter "S" will appear on the bottom line of ths screen. This letter stands for "SCOPE".

In the graphics ~ode, a box with a cross-hair in the middle is first raised on the graphic~ screen. This box represents, as previously described, the "Scope" which can be ~ ~ ....
:: , ' .

r~ ~

moved around within the limits of the screen using the above-discussed arrow keys. The "Scope" can be made larger or smaller by using the "PAGE UP" or "PAGE DOW~J" keys respectively.

As mentioned, the scope is used for zooming. The zooming feature is activated by a function key Which acts to enlarge and display whate~er appears within the scope window. A previous window can be recalled using the ''ALTI' key along with the function key which then displays the previous map display. In addition, the letter keys "U", "D", "L" and "R" allow the user to re~pectively move the entire map up, down, left and right. The screen can thereby move half way in any direction, but still maintain the same scale i~ the user wishes to see something at the edge of the screen.

The scope can also be used in co~bination with function keys to perform various graphic input functions such as relocation of a pick-up or delivery point or of a vehicle.

In the text mode, the user can move freely among the trips to be dispatched. As previously described, each trip is represented by a line on a transaction screen. The arrow keys are used to move the cursor along each row and column on the screen.

The operation of the function keys is as follows~

. -.

Function Number Function Identifier ~escr1pti~on Function 1 Help List of Command~ to be displayed on the Text Screen. Pres3ing any key will return the User to where they left o~f.
Function 2 Toggle The F2 switches the system from a text to a scope mode and back again.
Function 3 View Pickup InPo. Moves the cursor on the Text Screen to display Pickup Information for that trip. That information includes special instructions and latest time of arrival-.
The destination is also displayed.
Function ~ View Destination This function moves the Inform~tion cur~or to the portion of the activity screen which display~ destination infor~ation. Special instructions for the destination o~ the current trip are displayed across the top. Latest time of arrival is also displayed.
Function 5 View Extra Moves the cursor to the Information portion of the activity screen which displays the unit field and pickup destination confirmations.
Also time windows and price of the current trip are displayed.
Function 6 Dispatch Query Menu Displays dispatch query menuO

:, , ~ , - . ,, , : : , - , .I , , . : ; : : ,~

::

Zf)~

Function 7 Display Cand.idate The F7 sy~tem cor~and Unit causes the System to search ~or candidate units~ As previously discussed, khe candidates are listed by color indicating the relative merit of each choice. No automatic dispatch occurs.
Tha final decision remains up to the user.
Function 8 View Original W$ndow Thi3 F8 ~unction causes the original window to be displayed on the graphic screen.
Function 9 Zoom Causes the contents of the ~cope to be enlarged and drawn on the graphic screen~
ALT Function 2 Recorder Itinerary This function allows the user to ~hange khe order in which ~tops will accomplished. When pressed, ths system then prompts the user for the unit number. Once done, the user will be prompted to position thQ arrow of the scope ov~r the point to be reordered. When this is entered, the stop will be deleted and the system will guess the new plac~ that it is to be inserted. once the stop is being reinserted, the system will prompt the user ~or another point to be reordered.
ALT Function 3 Input Pickup Point By pressing th~ F3 key, the current pickup point will be repositioned at the center o~ the scope.
This in~ormation is automatically updated in thQ file.

: . . - :. . , : . . :,, ,;

..
,, . .:

ALT Function 4 Input Destination Repositions the destination in the same ~anner as descr.ibed above with respect to ALT
~unction 3.
ALT Function 5 Input Unit Position By pressing the ALT F5 keys, a unit is repo~itioned at the center of the Scope~ This function operates by first responding to ths system query o~ the unit number.
Th~ desired unit number should be then entered.
If the unit already has an itinerary, it will ask wh~ther the driver is already ther~, and whether the driver is on hi~ way.
ALT Function 6 Reconnect Network When pressing the ALT
and F6 function Station keys, the us~r i~ que~ied whether they wish to -de~troy th~ old connection. If they type "YES" they mu~t press any key and the ~tation will be disconnecked. When all displays are disconnected in the system, the screen will show a sy~tem disconnect message at the bottom. To get the network up and running again, the ALT and F6 keys are pr~ssed again. The user will the~ be asXed whether they wish to destroy the old connection. Upon answering "YES", they will then receive a message "WAIT FOR OT~ERS, THEN
PRE5S ANY XEY". By pressing any key the syste~ will b~ reconnacted and an update of all the thing~ that have been done while that unit was disconnected will be displayed.

.
-i . , , '` : ~ ' ' `:
.. .
.
, . .

ALT Function 7 Select Unit for Allows the di~pa~cher to Display view soma or ~11 of the units on the graphics screen. The user must enter the unit number which ~hen causes all of the units to be displayed on the graphics screen.
By pressing a "ZERO" all of the units will then be erased.
ALT Function 9 View Previous Cau~es the previous window Window to be displayed on ~he graphics screen.
ALT Function 10 Exit Causes the program to exit to the DOS PROMPT. This is done without losing any information. AIl auto~atic updating will still occu~.
Shift Function 1 After M~dnight ~utomatically changes the date on the system.
Automatically load~ all of th~ pre-scheduled, tomorrow and reservation information resident in the system memory to the n~w day. Once activated, all the ~ s ~or that day as well as the current trips which are incomplete are sent to all the work-stations in the system.
At midnight the date on the botto~ of th~ lefthand corn~r of all of the screens will begin to flash. This is a reminder to press the SHIFT Fl KEY.
The date will stop flashing once that is completed.
SHIFT Function 2 SSM Displays the system status management ~creen.
SHIFT Function 3 S~andby Units Allows the vehicle user to view all o~ the units with nothing to do. These units will be represented on the graphic~ screen.

, .: . . , ,: . ~ . ::

; , ~ ,::

~n~

5HIFT Function 5 Debug Key Sends a copy of the contents of each transaction screen to a debuy file. These are ~tor~d in a memory for later reference by a service representative.

SHIFT Function 6 Send Transaction Used in the caae of a File syskem failure in order to save the system functions.

SHIFT Function 9 Image Making Causes the system to generate a special file which will allow the contents of a graphics screen to be alltomatically recorded on film. This ~unction i8 a special function not normally used during dispatching op~rations.

9. The Dispatch Q~ ue Tha afore-described subrout~nes and functions operate on a dispatch queue which is a file of all transactions for a singl~
shift. At system waXe-up after each shift is changed at mi~night, the dispatch queue is loaded automatically into every workstation including order entry work-stations. The kind of transactions that are loaded, include pre-scheduled jobs for the current day of work, jobs entered for the n~xt day, and incomplete or overshift jobs from the previous shift. As previously mentioned, the dispatcher i~ notified in advance of any pre-scheduled jobs with specified picXup times.

- 5~ -'~
, ,.
', ~' - ,.

The dispatch queue file is a list o~ all jobs in job number sequence with its primary sort being accomplished by call priority. Once the vehicle i5 assigned to a given transaction, the job disappears from the list of undispatched transactions.

Transactions are entered into the queue at the order entry program level. All information posted in the queue is instantaneously transmitted to a date dispatch queue file. The newly entered information is signalled to the user by a bell on the screen. Transactions that are modified or del~ted at the order entry level are signalled by a low buzz tone on the screen.
The maximum allowable number o~ transactions ~or ~he queue is 10,000 per day. A single~dispatch station may handle no more than 3,400.

10. System Status Mana~ement Program (SSM~

The SS~ is enterPd in the order entry routine as described above. The SS~ maintains vehicle in strategic locations when they are not performing.~ Once the selections have been entered at the order entry stage 200, the plans are entered into the dispatch work-stations and are created to coincide with peak times of days, or other considerations. To verify compliance, the SHIFT and F2 keys are pressed, such that the current plan for that day and time are displayed. The display screen for the SSM is shown below.

Posts Vehicles Post 1: 412 Palm Canyon Veh 1 ALS 128 13:45 Veh 2 : ~LS 612 13:52*
Veh 3 : NEV 341 13:32 Po~t 2: Central Station Veh 1 : ALS 412 Veh 2 : BLS 231 13:44*
Veh 3 : NEV 111 Post 3: Sunset ~ Vine Veh 1 : ALS 439 13:30 Veh 2 : BL5 124 Veh 3 : NEV 222 13:38 Press ESC to return or ~Return> to escape As shown, vehicles are positioned at a given post. Each vehicle is assigned a vehicle type (e.g., ALS, ~LS). I~ the vehicle is not at that post, but is on its way there, the estimated time of arrival will be displayed next to the vehicle unit number. If there is no unit at tha~ post and none on its way, th~ screen at that line will ~lash, meaning that correction is required. Between the estimated time of arrival and the vehicle type, the unit number is identified. If a vehicle has ::
been downgraded (in other words, a high priority vehicle as a standby has been downgraded to a low priority vehicle), there will be an asterisk at the end of each line.

. ~ 61 -. ~ , .
~, . . .

- . . :
.

;~n~l.r~

To insure compliance with the SSM, the graphic screen will display all the vehicle units which are not on post according to the curren~ plan. The graphic screen will also display current post locations as round red rings, with the post number appearing inside them. A vehicle unit i~ positioned at the post as follows:

1. Position the cursor on the flashing vehicle number on the text screen and press the F7 key. The screen will then display the three candidate units for that post on the graphic screen.

2. Look at the available units on the graphic screen and assign the vehicle unit whose current loca~ion i~ closest to the post. To do so, the usar selects a vehicle by pres~ing "ALT F5,"
which will then require the user to enter a vehicle unit number.
The user must then enter the post number that tha.vehicle is to be moved to. The system will then request whether the vehicle unit is enroute to the post. If the answer is "YES", the post location will be added to the unit's itinerary and will display the unit number and estimated time of arrival on the SSM screen. If the unit is already at the post location, the unit number will be displayed on the SSM screen. In either case, the line on the text will cease ~lashing because the operator is in compliance with the SSM Plan.

C. The Moblle Di~ital D~spatch Pro~am Referring now to FIG. 4, the mobile digital dispatch program (MDDS) functions to prompt in~ormation involving dispatch , , ~: .

decisions from the dispatch program. The MDDS then effects changes at the downstream locations of the affected vehicle's itinerary and drives those changes through to the mobile terminals. Thus, the MDDS prompts information at one end c.ld sends the revised order o~ jops at the other end. The jobs are automatically reshuffled based upon the changed priorities. The driver~ may also be allowed to reshuffle the job order at the mobile terminals based upon certain dispatch or user defined constraints.

The MDDS includes a serial input (SIN) routine 410. That routine requests another stop in the mobile terminals' internal tables. In addition, a "B~T~US'I input 420 and a keyboard input 438 are also utilized. The output event for the MDDS program include ths serial output routine 430, the "~ITBUS" output routine 432 and the video display console statu routine 440. In descending order of priority, events are serviced from the SIN
412, the "BITBUS" 420, the Serial Output (SIO) 430, the "BITBUS"
output 432, and the keyboard 4380 More particularly, the serial input 410 provides data directly to the serial input buffer 412. In~ormation in the buffer 412 represents incoming messages received from the mobile terminals (See FIG. 18) and from the dispatch workstations. That information includes the compl~tion o~ a 5top, the confirmation of various tasks and d~iver queries. Thi information will in turn cause tho MDDS program 400 to eventually request the "BITBUSI' output 432 to make another stop in the itinerary that is stored in , the dispatch program 300. As such, the serial input buffer 412 will send a confirmation buffer signal to the output bus along line 435. All of the information in the serial input buffer 412 is stored as an internal table 414, indicating the mobile identification statu~ of each vehicle (MIST). ~n~ormation in the MIST table is, in turn, sent via line 415 to the MIST transaction files 416.

The "BITBUS" input routine 420 provides four basic functions. First, if the input is a transaction ~ile modification, then the input is provided to the MIST along line 428. No external output events are generated ~rom such a change.

The second function occur when an assignment interruption input arrlves from the dispatch program 300. Th~ interruption indicates that a vehicle's current itinerary has been revised by a stop insertion and that the vehicle'~ immediate destination has to be rerouted. Such an interruption will causQ a signal along line 422 to the reorder MIST routine 424. The routine 42~ will automatically reorder the MIST file by providing reorder commands through a serial output buffer 426 which will then act to reorder the MIST table 414. Accordingly, the calculation of downstream pickup~ will be readily av.ailable.

The third input is an assignment notification which indicates that the vehicle has been assigned a new stop. The as~ignment notification information is al~v sent along line 428 to the ~IST 414.

, ,~
. . . .

Finally, the fourth "BITBUS'I input involves pre-fetching the vehicle's next stop. That function involves the "BITBUS"
responding to a pre-fetch input by placing a ~etcH request along line 428 fsr later preprocessing by the MIST ~14, the serial output buffer 426 and the serial output 430. Other "BITBUS"
messages include noti~ication of cancellations, requests for vehicle status and notification of vehicle breakdowns.

The serial output routine 430 checks for and clears any outstanding messages in the serial output buffer 426. The communications are performed along lines 427 and 429, respectively. In addition, that information is checked in relation to the MIST tabl~ 414 for any new entries. Those new entries are filed in the serial output bufger 426 and then returned to the serial output routine 430.

The "BITBUS" output 432 checks the serial input buffer 412 along lines 434 and 435 for any messages coming in from the mobile terminals. When messages are received, the "BITBUS" output 432 sends such information out directly to the dispatch program showing the vehicle's next ~top in relation to the last MIST
entry. The mobile terminal also checks the MIST for its next stop through routine 431. If the MIST is found to be empty at line 442, it will then send the request to the dispatch program 300.

Pre-~etch stop~ output by ths serial output 430 to the mobile terminal are kept hidden from th~ vehicle driver until all upstream stops on the itineraxy are completed. The keyboard function 435 under the ~DDS is reduced merely to a passive task.

An MDDS operator may send global text messages along line 444 to all vehicles or perform housekeeping tasks and request status screens, etc/ Those events directly e~fect the video ~isplay console 440 and also generate messages to the serial output unit 430 or ~he "BITBUS" output 432. The mobile terminal as shown in FIG. lB communicates to the system only through the MDDS Software.

Although not illustrated, the mobile terminals a~ shown in FIG. lB include a mobile terminal queue which is similar to the MDDS queue, but contains fewer fields. The mobile terminal queue can be user co~figurable to allow drivers to reshuffle their vehicle itineraries.

D. Finance and Accounting ~rog~

As shown in FIG. 5, the system includes the capability of utilizing a financ~ and accounting program SOO. The program has the sa~e open architecture and ~C-compa~ible design philosophy of the order entry, dispatch and MDDS programs. Moreover, the program 500 includes a dBASE management system i~ order to share the same memory handling .~unctions a~ the other programs. All que files are sent through a call clearing function that edits all data captured in the dispatch (CAD) environment and allows for keyboard entry of additional information taken from actual "paper records" of field occurrences. At the call clearing step, all billing codes and procedures or diagno~tic codes are added to the record. Also at that time, the Transaction file is downloaded to all the other module~ in the "business system." All such modules share a common dBase data base. Information fields that feed each ~ - 66 -- ~ ~

:; ;
: ~ .

module, for example, inventory usage, payroll information, vehicle usage, etc. are updated in each module.

The accounting program 500 allows for all accountiny and inventory control function~ to ba readily managed. The functions also enabl~ information to be ea~ily added, customer reports to be readily created and invoices and mailing labels to be quickly generated. I~ an inventory item is used during a run, it would not only show up on the invoice but it would also be deleted from the inventory. A reorder would also be automatically triggered and be subject to review by a quality control program to determine compliance with various protocols. Moreover, the so~tware is menu driven and readily access~ble and understandable by any user.

ThQ accounting library includes a general ledger 510, a billing inventory control and an open item account~ receivable routine 500. Other function~ include an accounts payable and check writing program 530, a payroll and labor accounting program 550, a purchase order processing program 540, a service equipment and maintenance program 560 and a fixed assets management routine 570. Accounting programs, such as those included in the Database Accounting Library available from SBT Corporation o~ Sausalito, California may be used with the present invention.

With respect to the general ledger program 510, all financial reporting capabilities are maintained on a period-to-date and a year-to-date balance ~or a number of years. Features included in thi~ routine are consolidated in comparative income statements, balance sheets and automatic multiple-distribution entries.

The billing, inventory, and open item accounts receivable routine 520 performs all of the billing inventory control and accounts rec~ivable functions ~or th~ system. In addition, cu~tomer and inventory label~ can be printed and ~he sy~tem will also provide high speed lookup of cu~to~er and inventory codes.
Cash receipt registers, items receivable, aging and user definable reports are inclu~ed in this package. The system can also track back orders and analyze sales and gross margins (on a per item basis).

Th~ accounts payable and check writing ~unction 530 provides a complete accounts payable sy~tem including aged cash requirements, check register generation and di~tribution of payments to the general ledger accounts.

The payroll and labor accounting routines 540 maintain all payroll and labor distribution information. These include, but are not limited to, payroll tax calculations, and deductions made for employees during regular payroll periods. Calculations of gross earnings will include hourly, salary, commission and piece work information. Separate tax computation tables may be included for each state covered by the system.

The purchase order processing program 550 provides a complete purchasing and inventory control system. The system includes a vendor and inventory label printing routine as well as , . .

,. ~

: ,, , ~

report generation for inventory reordering, back orders, purchase order status by item, and vendor and buyer related data.

The service and equipment maintenance routine 560 tracks maintenance and service contracts and lease payments in user-definable equipment categories. This module also schedules upcoming maintenance, records servic~, contrac~ activi~ies and also tracks purchasing and leasing ~rom different vendors.

. The fixed asset management routine 570 provides a record for each asset and calculates depreciation using a variety of different depreciation methods. In addition, the routine generates loan amortization schedules and combines principal and interest rate payments for specifîed equipment.

E. Insurance Claims Routine Th~ insurance claim modul~ 600 edits and processes Health Care Financing Administration (HCFA) H1500 Claims to third party payers including Medicare, ~edicaid and commercial insurers. The insurance module 600 is designed to incorporate the speci~ic edits required by any client's third party carriers and fiscal intermediaries. This ensures that only clean claims are forwarded. A~ the insurance module i8 integrated with the dispatching system so~tware, the r~quired data is entered automatically by a custom download program.

The system 600 works in such a manner that claims meeting insurance carriers t :'edits" do not need additional operator input.

However, claims that do not pass background edits are brought up .
, ~ , , individually. The claims data are formatted into a HCFA 1500 screen that emulates the HCFA form. Based upon the library of ~dit~, invalid da~a ~ield~ are readily highlighted and data entry skips to the error portions of the screen only. Where information is not immediately available, the claim can be set asid~ and called up and corrected at any time in ~he future.

The first eligible edited claims are batch transmitted to an electronic claims processlng service on a daily basis. Then detailed reports are generated to th~ client's side of all the claims transmitted. After claim submission, the reports detailing the claims received and accepted are returned to the client. The incorrect claims are repo~ted out and errors are provided in order to correct such claims for resubmission.

The insurance module ~no incorporates a varie~y o~ -management report~ to track the number~ and value~ of claims received and paid. Moreover, the insurance module is designed to interface with the electronics claims processing services that handle claims for the major insurance carriers, such as that of~ered by PCX, Inc. of Elwood, Indiana.

A~ shown in FIG. 6, the insurance modul~ 600 incorporates several modules, the last of which feeds the processed and edited information to the bu~iness system module 500. The insurance module 600 receives its in~ormation ~rom the CAD system, as previously described. The informatioh i~ first fed to a completed dispatch "Que" ~ile 610. All Que files are then sent to a call clearing software module 620 which edits all data captured in the , .
. .

:

- znn~

display (CAD) environment and allow5 ~or keyboard entry of additional information taken ~rom actual "paper records" of f ield occurrence~, also as previously descrlbed.

The output ~rom the call clearing software module 620 is ~ed to the HF 1500 claim proces~ing module 630, as previously described. Upon completion o~ the claim proces~ing, the transaction file is downloaded to all of the other modules 510, 520, 530, 540, 550, 560 and 570, which form the "business system"
or finance and accounting program 500 of the present system.

Although only a preferred embodiment is specifically illustrated and described herein, it will be appraciated that many modifications and variations of the present invention are possible in light of the above teachings, and within the purview o~ the appended claims without departing ~rom the spirit and intended scope of the invention.

Claims (43)

1. An integrated vehicle dispatch system, comprising:

management means for automatically managing selection and assignment of said vehicles;
coordination means for coordinating scheduling of vehicle pickups and deliveries based upon said selections by said management means; and communication means for providing information to said integrated vehicle dispatch system such that said vehicles are efficiently utilized.

2. The vehicle integrated dispatch system according to Claim 1, wherein said management means includes searching means which enable information to be automatically searched and provided to said integrated vehicle dispatch system.

3. The integrated vehicle dispatch system according to Claim 2, wherein said searching means includes a transaction searching capability, an address searching capability and an account searching capability whereby address, transaction and account information is automatically provided to said management means.

4. The integrated vehicle dispatch system according to Claim 3, wherein said address searching means is adapted to receive 911 emergency information input and automatically fill in missing address data from said 911 emergency information input.

5. The integrated vehicle dispatch system according to Claim 2, wherein said management means further comprises a rolodex routine whereby a user is automatically provided with all information most closely related to that search performed by said user.

6. The integrated vehicle dispatch system according to Claim 2, wherein said management means further comprises a posting function which enables the user to flush out and post all transactions based upon real-time clock periods.

7. The integrated vehicle dispatch system according to Claim 6, wherein said posting function enables a user to post transactions for today, post transactions for tomorrow, post transactions concerning reservation dates previously established by a transaction search, and post transactions in multiple forms.

8. The integrated vehicle dispatch system according to Claim 1, wherein said management means further comprises a system status management module allowing for identification of resource posts which are defined by civic address,

9. The integrated vehicle dispatch system according to Claim 8, whereby said system status management module allows for a user to create management plans for specified days of a week at specified hours such that said vehicles can be assigned to said posts based upon said specified days and hours.

10. The integrated vehicle dispatch system according to Claim g, whereby said posts are defined by a number of vehicles required for each post and a type of vehicles required for each post.

11. The integrated vehicle dispatch system according to Claim 10, wherein said vehicle type is defined by vehicle equipment characteristics and by on-board personnel qualifications.

12. The integrated vehicle dispatch system according to Claim 11, wherein said system status management module is raised on a user's screen within a preset time period prior to said specified day and hour such that said operator can assign resources to posts in accordance with said management plan.

13. The integrated vehicle dispatch system according to Claim 3, wherein said address searching capability performs a search on a metropolitan area and then on a civic address until a match is found.

14. The integrated vehicle dispatch system according to Claim 13, whereby when a match is not found by said address searching capability a close name found during a subsearch is provided.

15. The integrated vehicle dispatch system according to Claim 14, whereby said address searching information is coordinated with a geo-based file in order that addresses are automatically mapped onto a video display of a given delivery area.

16. The integrated vehicle dispatch system according to Claim 3, whereby said transaction searching capability searches a first occurrence of a transaction for customers sequentially until a desired transaction is found.

17. The integrated vehicle dispatch system according to Claim 16, whereby if a transaction is not found under a current date, a pop-up calendar is displayed in order to choose previous dates for transaction tracing.

18. The integrated vehicle dispatch system according to Claim l, wherein said management means further comprises a pricing program whereby automated prices are appended to transaction records.

19. The integrated vehicle dispatch system according to Claim 18, wherein said automatic pricing program bases prices upon a base rate, a rate per additional mile, additional charges, contractual adjustments and special rates applying to specific accounts.

20. The integrated vehicle dispatch system according to Claim 1, wherein said management means further includes a management monitor display which provides a snap shot of key operational statistics of a given time period of operation of said integrated vehicle dispatch system.

21. The integrated vehicle dispatch system according to Claim 1, wherein said coordination means includes a graphic display revealing an entire map of the delivery and pickup locations for said vehicles.

22. The integrated vehicle dispatch system according to Claim 21, wherein said graphic map display employs icons indicating said pickup location and said delivery location.

23. The integrated vehicle dispatch system according to Claim 22, whereby said graphic map display highlights a proposed minimum vehicle route from said pickup location to said delivery location.

24. The integrated vehicle dispatch system according to Claim 23, whereby said minimum vehicle route is calculated based upon a directional network link ordered by ascending node numbers.

25. The integrated vehicle dispatch system according to Claim 24, whereby said nodes are organized such that a starting and ending node of one of said links represents street and network intersections.

26. The integrated vehicle dispatch system according to Claim 25, whereby travel times for each link are determined as a function of said link distance and a road category.

27. The integrated vehicle dispatch system according to Claim 26, wherein times for each link are automatically adjusted during different hours of a day such that traffic conditions, accidents, road repairs and other circumstances can be factored into time determinations.

28. The integrated vehicle dispatch system according to Claim 27, wherein the said minimum path is calculated by iterating all nodes connected to a starting point, calculating a total time for each branch of said node and determining a total time of travel between a beginning node and an ending node for each vehicle, such that a minimum travel time per vehicle is determined.

29. The integrated vehicle dispatch system according to Claim 1, wherein said coordination means further comprises a candidate selection program for identifying best candidate vehicles to be used in a given transaction.

30. The integrated vehicle dispatch system according to Claim 29, wherein said candidate selection program identifies three best candidates for a current transaction, said determination being determined upon weighted criteria pre-selected by a user.

31. The integrated vehicle dispatch system according to Claim 30, wherein said weighted criteria include a time to pickup, a time to delivery, a distance the vehicle must travel to said pickup and delivery points, and capabilities of each of said vehicles considered.

32. The integrated vehicle dispatch system according to Claim 1, wherein said coordination means further comprises a vehicle assignment means, wherein optimal insertion points for a pickup and for a delivery are displayed on a graphic display.

33. The integrated vehicle dispatch system according to Claim 1, wherein said coordination means further comprises a confirmation means that provides acknowledgments of assignments on a per vehicle basis.

34. The integrated vehicle dispatch system according to Claim 33, wherein said acknowledgments include arrival at a pickup location, leaving a pickup location, arrival at a destination location, and clearing delivery at said destination location.

35. The integrated vehicle dispatch system according to Claim 1, wherein said coordination means includes a transaction queue that pre-schedules jobs up to a year in advance.

36. The integrated vehicle dispatch system according to Claim 35, wherein said daily transaction queue acts in conjunction with a real-time clock to cause a reminder signal to be activated a set time period in advance of a real time event.

37. The integrated vehicle dispatch system according to Claim 36, whereby said daily transaction queue provides emergency deadline signals when a pre-scheduled time period has expired.

38. The integrated vehicle dispatch system according to Claim 37, wherein said real-time clock affects date change verification and said integrated vehicle dispatch system, such that a midnight transition is detected activating all current day's files to be transferred automatically to a next day date.

39. The integrated vehicle dispatch system according to Claim 1, wherein said graphic display includes a scope mode which allows a user to expand or contract said map over a particular area of said map.

40. An integrated dispatch computer system, comprising:

an order entry workstation comprising a plurality of microcomputers connected via a "BITBUS" network to one another and via modem to an input line;

a dispatcher workstation comprising a plurality of microcomputers having text and graphics screens associated with each computer, wherein each of said microcomputers is connected via a "BITBUS" network to each other and to said order entry workstation;

a mobile digital data microcomputer connected to said dispatch workstation by said "BITBUS" and to a radio transceiver in order that information received by said dispatch workssation is sent by said transceiver to a plurality of vehicles; and a mobile vehicle microcomputer connected to a transceiver such that information received by said mobile digital daka device is displayed to a driver of a mobile vehicle.

41. The apparatus according to Claim 40, whereby said integrated dispatch computer system is fully redundant such that input in one microcomputer are stored in memories of all of said microcomputers.

42. The apparatus according to Claim 41, wherein said integrated dispatch computer system is tied into a vehicle locator information network based upon a LORAN format such that said system displays information in the form of detailed maps.

43. An integrated vehicle dispatch system, comprising:
searching means for finding information relating to a dispatch order received by said vehicle dispatch system;
accounting means for providing automated account related information for a received transaction;
candidate selection means for selecting an appropriate vehicle for said received transaction:

assigning means for automatically assigning said candidate vehicle to said received transaction;

monitoring means for following progress of said vehicle through said assigned transaction;

updating means for automatically updating information relating to said assigned transaction based upon actual vehicle location; and reporting means for reporting vehicle progress on a graphic map display.