WO2008030531A9

WO2008030531A9 - Systems and methods of analyzing and identifying optimizations in transportation networks

Info

Publication number: WO2008030531A9
Application number: PCT/US2007/019470
Authority: WO
Inventors: Cheryl D Martin; David L Strohecker; Jamie P Cooke; Shibani B Shah; Calvin Williams
Original assignee: Us Postal Service; Cheryl D Martin; David L Strohecker; Jamie P Cooke; Shibani B Shah; Calvin Williams
Priority date: 2006-09-08
Filing date: 2007-09-07
Publication date: 2008-09-12
Also published as: WO2008030531A8; WO2008030531A3; WO2008030531A2

Abstract

Systems and methods of analyzing and identifying optimizations in transportation networks are provided. The methods include defining a scope of analysis in a transportation network based on a variety of factors including specified attributes of areas, routes, trips, and facilities. The transportation network may be further analyzed by defining facility groupings which group facilities by a selected level of tolerance, and consolidating trips among the facilities which have been grouped together.

Description

SYSTEMS AND METHODS OF ANALYZING AND IDENTIFYING OPTIMIZATIONS IN TRANSPORTATION NETWORKS

BACKGROUND OF THE INVENTION Field of the Invention

(0001] This application relates to transportation network management. More particularly, the application relates to optimizing existing transportation routes utilizing computer-implemented routing and scheduling analysis.

Description of the Related Art

J0002] In large organizations that are tasked with transporting cargo to many destinations, transportation networks and schedules often become so complex that it becomes difficult to effectively analyze the network to create cost saving opportunities. Moreover, because the analysis of transportation networks is inherently complex, existing systems and methods developed for the purpose of analyzing the networks are generally tailored for use by transportation planning experts and are not generally configured to allow non-experts to create complex transportation models for analysis. Therefore, what is needed is a transportation analysis system configured to allow non-technical personnel to create, analyze, and optimize complex transportation networks.

SUMMARY OF CERTAIN INVENTIVE ASPECTS

|0003] In one embodiment, a computer-implemented method for identifying transportation routing solutions in a transportation network is provided. The method includes receiving data relating to the transportation network for analysis, the data including trips, routes and schedules. The data is preprocessed using statistical analysis software. A user is presented with a selectable option for defining a scope of analysis at a first level of specificity and receiving an input defining the first level of specificity. A user is then presented with a second option for defining the scope of analysis at a second level of specificity if the received input includes a specified area. The second level of specificity may be an indication that the routes are wholly contained or not wholly contained within the specified area.

[0004] In another embodiment, a computer-implemented method for identifying transportation routing solutions in a transportation network is provided. The method includes receiving data relating to the transportation network for analysis, the data including one or more facilities, producing a facility grouping based on one or more attributes of the facilities. In producing the facility grouping, the method may include presenting a user-selectable option for defining a facility grouping tolerance such that the tolerance is related to the one or more attributes of the facilities. The method may further include receiving input indicating the selected facility grouping tolerance and placing, based on the selected facility grouping tolerance, one or more of the facilities into a facility group.

[0005] In yet another embodiment, a computer-implemented method for identifying transportation routing solutions in a transportation network is provided. The method includes receiving data relating to the trips, routes, and facilities. The trips may each include an origin facility and a destination facility. The method may also include providing a user-selectable option for locking down one or more of the plurality of trips and identifying one or more of the plurality of trips eligible for consolidation, the identifying being based at least in part on the received data and the locked down trips. The received data may then be modified in accordance with the identified trips.

[0006] In yet another embodiment, a method of identifying transportation routing solutions in a transportation network is provided. The method may include receiving data relating to the transportation network for analysis. The data may comprise a first transportation routing solution and may include route data, schedule data, and facility data. The method further includes identifying one or more of the plurality of trips for consolidation based at least in part on the received data. Based on the identified trips a second transportation routing solution is determined. Differences between the first transportation routing solution and the second transportation routing solution are then displayed to a user, allowing the user to select some of the differences. Based on the user selections, a third transportation solution is then calculated.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 is an example computer environment suitable for managing and optimizing a transportation network.

|0008] Figure 2 is a block diagram of a dataset and data packages. 10009] Figure 3 is an example of a basic database table definition for a trip record that may be used in a transportation network such as that shown in Figure 1.

JOOlO] Figure 4 is a screen shot of an example of a main menu user interface.

|0011] Figure 5 is an example of a scenario definition user interface.

|0012] Figure 6 is an example of a scenario viewer.

|0013] Figure 7 is an example of a facility grouping management interface.

|0014] Figure 8 is an example of a facility viewer.

[0015] Figure 9 is an example of a trip lock down interface.

[0016] Figure 10 is an example of a data editor which allows a user to correct data values.

[0017] Figure 1 1 is an example of an optimization parameters input interface.

[00181 Figures 12A-12D are examples of various display labs that may be included in a results summary interface.

[0019] Figures 13A-13C arc examples of various aspects of a model detail interface.

[0020] Figure 14 is an example of a recommendation manager.

[0021] Figure 15 is a flowchart depicting a computer-implemented method for identifying transportation routing solutions in a transportation network.

[0022] Figure 16 is a flowchart depicting a method for defining facility groupings in a transportation network.

[0023] Figure 17 is a flowchart depicting a method for consolidating trips in a transportation network.

[0024] Figure 18 is a flowchart depicting another method for identifying transportation routing solutions in a transportation network.

DETAILED DESCRIPTION OF CERTAIN INVENTIVE EMBODIMENTS [0025] This disclosure describes systems and methods of analyzing and identifying optimizations in transportation routes and schedules. Certain embodiments may be implemented as a computer application that runs on a computing device. In some embodiments, parts of the application may be run or accessed through a computer network. In one embodiment, certain aspects may be implemented in a client/server application environment in which certain client computers access the computer application over a computer network.

[0026] With reference to Figure 1 , an example of an environment suitable for practicing certain embodiments is provided. The environment may include one or more client computers 1 1. The client computers may be any type of computer, including but not limited to computing devices such as personal computers, handheld computers, laptop computers, tablet computers, or other computing devices. The client computers 1 1 may be configured to connect to a network 12. In one embodiment, the network may be a wide area network such as the Internet, for example. Alternatively, the network may be a local area network or some other type of network. Also connected to the network 12 may be a transportation analysis system 10. The transportation analysis system 10 (also referred to herein as "TAS 10") may be a software application stored on a single computing device or distributes across more than one computing device as shown in Figure 1.

|0027] In one embodiment, the TAS may include various components that perform certain functions within the TAS 10. The TAS 10 may include one or more web/application servers 14. The application servers may be configured to run software that receives requests for content from client computers 11 over the network 12, and responds to those requests by sending content over the network to the client computers 1 1.

[0028] In one embodiment, portions of the TAS 10 may also be connected to a database server 16. The connection with the database server 16 may be a direct physical connection, or some more remote type of connection such as a network connection. In one embodiment, the database server 16 may be a "back-end" server that is configured to store content that is accessed by the web/application server and sent to clients 1 1. The TAS 10 may further include one or more analysis servers 18. The analysis servers 18 may be configured to perform data and statistical analysis on data stored within the database server 16. The analysis servers 18 may be configured to run statistical analysis software packages such as SAS®, SPSS, JMP or the like. Although the server functionality is broken into various server components, one of skill in the art will appreciate that various network application configurations may be suitable for implementing systems capable of performing various aspects of the present invention.

[0029] Moreover, although the TAS 10 is described as being implemented in a client/server environment, one of skill will readily appreciate that the various functions performed by the network components referenced in Figure 1 may be performed on a single computing device, or on several computing devices. A standalone environment having no network connectivity may also be implemented in which the applications, data, and statistical analysis components and modules of the TAS 10 are each installed and accessed on a single computing device.

[0030] Referring now to Figure 2, stored within the TAS 10 (or more particularly, in the database server 16, for example) may be one or more datasets 20. The datasets 20 may generally include data relating to routes and trip schedules in a defined area. In one embodiment, the area may be defined as a particular geographical region. Datasets 20 may be updated on a regular basis to maintain up to date information. In one embodiment, the datasets are updated on a quarterly basis. Alternatively, the updates may happen more frequently, or even in real-time, to reflect instantaneously those changes made to the transportation network. Datasets 20 may be sub-divided into one or more data packages 22. The data packages 22 may be subsets of the datasets 20 that are carved out according to various criteria. In one embodiment, a data package 22 is defined according to a specific time period such as, for example, weekend trips between various points in the transportation network. Alternatively, a data package may be defined according to a specific location, such all trips originating or terminating at a certain location, area, or facility.

[0031] Aspects of the invention provide for various computer systems and computer-implemented methods for identifying transportation routing solutions within transportation networks. As used herein a transportation network may include one or more facilities. As used herein, a facility may be any location that may serve as an originating location or destination location for a route defined in the transportation network. A route may include a specific path from an originating (or beginning) location or facility to a destination (or ending) location or facility by way of zero, one, or more intermediate locations or facilities. For a given beginning and ending point in the transportation network, there may be any number of different routes that may be defined. For example, there may be a plurality of available routes from a Los Angeles facility to a Denver facility. One route may include traveling solely on interstate highways such as 1- 10, 1-15 and 1-70 to reach the destination. Another route may be partially on interstate highways and partially on other types of roads. Yet another route may avoid interstate highways altogether. The transportation network may also include a plurality of trips. As used herein, a trip may be any scheduled departure and arrival of a vehicle between two facilities. A trip may be a direct trip which includes only an originating facility and a destination facility. A trip may also be a multi-stop trip which includes stops at one or more facilities between the originating facility and terminating facility.

[0032] Referring now to Figure 3, an example of a database table definition for a trip 300 is provided. Although a specific data structure is described herein, one of skill in the art will readily appreciate that this example is only one of many ways that data about trips may be stored and modeled. A trip may include a trip identifier 302 which may be an alphanumeric string which may uniquely identify a particular trip. The trip 300 may be associated with a route identifier 304, which may be an alphanumeric string that identifies a particular route taken when completing the trip. A multi-stop trip may be associated with more than one route identifier 304, as the trip may include stops between multiple facilities. Trips may also include a frequency identifier 306. The frequency identifier 306 may indicate how often the particular trip is run within the transportation network. In one embodiment, the frequency identifier 306 may indicate which days of the week the trip is run. The trip data may also include an effective date identifier 308 and a discontinued date identifier 310. These data fields may be in the form of date values which represent the beginning and termination date for the trip, respectively. The trip definition may further include a frequency per year identifier 312. The frequency per year identifier 312 may include data indicating average number of days per year the trip is run. The trip data definition may further include an annual trip miles field 314 which includes data related to the total number of miles traveled on the trip in a particular year. The data definition may also include an annual cost indicator 316 which may indicate how much money is spent on the trip in a year.

J0033] A trip data definition may also include a vehicle type indicator 318. This field may include data indicative of a vehicle type that is used to run the trip. In some embodiments, more than one type of vehicle may be used for a particular trip. The trip table definition may also include a capacity indicator 320. The capacity indicator 320 may include data related to the number of containers of cargo that may be carried on the trip.

[0034] In some embodiments, the trip table definition may also include fields for storing data related to the various stops that are made on the trip. For a direct trip, there is only a single stop (the termination location of the trip) about which data is stored. For multi-stop trips, there may be multiple stops about which data is stored. Each trip record may include one or more facility identifiers 322. In one embodiment, each facility identifier 322 is stored in a separate field. Thus, if there are 17 facilities associated with a trip, there may be 17 fields such as FACl .. FACl 7, for example, in the table definition. In some embodiments, facility identifiers 322 may take the form of facility codes for stops on the trip's routing. Each facility identifier 322 may be associated with a facility name 324 and a facility type 326, such as warehouse, distribution center, or some other facility type. For each facility identifier 322, there may be an area identifier 328 which identifies the area (e.g., the postal code) in which the facility resides.

(0035] Each facility identifier may further be associated with an arrival time 330 which represents the time that the vehicle arrives at the facility and a departure time 332 which represents the time that the trip is scheduled to depart from the facility en route to the next facility. When a vehicle arrives at a facility, it is often useful to determine whether additional cargo can be loaded onto the vehicle. As a result, the trip table definition may further include a vehicle utilization rate 334 for the vehicle upon its arrival at each facility 322. This information may be used to determine how much cargo can be loaded onto the vehicle when it arrives at a facility. Each facility identifier 322 may further be associated with a day count identifier 336. The day count identifier 336 may include data that indicates the total elapsed days that a trip is en route to the facility. The trip table definition may also include fields that store data related to the total number of miles traveled on the trip on an annual basis. This data may be used to help determine cost-savings that may achieved by eliminating the trip (as will be discussed in further detail below).

10036] In some embodiments, trips also may include cargo available and cargo required times associated with them. The fields include data related to when the cargo that is transported on the trip is made available for loading onto the vehicle, and they also include data related to the time that the cargo must be delivered to its destination in order for it to have adequate time to be prepared for its next trip.

[0037] Much of the data described in Figure 3 may be accessed, modified, and displayed via a user interface which includes various menus and input forms which allow a user to effectively identify cost-saving opportunities within the transportation network. Figure 4 provides an example of a main menu user interface 400 which may be presented to a user to allow the user to begin defining scenarios for analysis. In some embodiments, the main menu interface creates a scenario which may be used to analyze and model changes to an existing transportation network. As used herein, a scenario is a defined set of data which represents a sequence of events within a transportation network. By way of example, and not of limitation, a scenario may be based on a geographical breakdown of data related to the transportation network, such as transportation within a specific area of the transportation network. Another scenario may be based on a specific type of transportation network. For example, a scenario may be based on all transportation between certain types of facilities. A scenario may further be based on a particular facility, such as all transportation and trips originating or terminating at a particular facility.

[0038] The main menu 400 may include an input data specification interface module 402 which allows a user to specify or select the transportation network data that may be used to define the scenario. The exemplary interface may include a type of model selection element 404 which allows the user to specify whether they wish to create a new scenario or work with an existing scenario. The new scenario option selection element 405 is activated while the existing scenario options 406 are deactivated. The main menu may be configured to automatically display a dataset that is stored in a predetermined or default location.

[0039] In embodiments where the menu is configured in this manner, the dataset information will be automatically displayed in the dataset details display element 407. The main menu may also include a data package selection control 408. The data package selection control 408 is configured to allow the user to specify the particular data package 22 within the dataset 20 from which to create the scenario. The data package selection control 408 may be configured to have a specific data package 22 pre-selected when a dataset is accessed by the client system. In the embodiment shown in Figure 4, the "Data Package A" option has been pre-selected. When the user selects the "Import Active Data Package" button, the data package 22 selected in the data package selection control 408 is set for defining the scenario. If the user wishes to utilize another dataset 20 that is not stored in the default location, the user may select the "Select Alternative Data Package" button from the new scenario option selection element 405 and locate and select the dataset 20 for use in defining the scenario to be modeled.

J0040J In some cases, the user may wish to work with an already defined scenario. To work with an already specified scenario, the user may select the "Work with an existing scenario" radio button in the type of model selection element 404. When the user selects this radio button, the new scenario options 405 becomes inactive, while the existing scenario options 406 becomes active. In addition, because an existing scenario may be specified, the user may select a starting point from the starting point menu 409. In one embodiment, the user interface may be configured to activate only those buttons in the starting point menu 409 to which this scenario had previously progressed in its definition.

|00411 Referring now to Figure 5, a scenario definition interface 500 is provided. This portion of the user interface may be presented after a user, utilizing the main menu interface 400, selects a data package 22 from which to build a new scenario to optimize and model. The scenario definition interface 500 may include various display elements which allow a user to refine the data package 22 to select a specific scenario. In particular, the scenario definition interface 500 may be configured to allow the user to filter the imported data package 22 to help define specific scenarios of interest. In one embodiment, three filter options may be presented to the user in a query criteria display element 502. A first filter option may be an area filter 504. The area filter 504 may be populated with all areas which are included in the selected data package 22. The user may select one or more of the areas in the area filter 504 to indicate areas of interest for the scenario. In one embodiment, the trip filter may also include an area selection element 506 which allows the user to choose between trips wholly contained in the selected areas and trips not wholly contained (but at least partially contained) within the selected areas.

[0042] The query criteria display element 502 may also include a facility filter 508. The facility filter 508 may be populated with a list of all facilities that are in the selected data package. The query criteria display element 502 may further include a route filter 510. The route filter 510 may be populated with all routes that are part of the trips included in the selected data package.

[0043] Each of the area filter 504, facility filter 508,. and route filter 510 may be selected in combination. As a result, all three of the filters may be applied simultaneously. Upon selecting the desired filters, the user may then select one of the processing options 512 to activate the filtering process. Included in the processing options 512 may be a filter activation element 514 and a filter reset element 516. Selecting the filter reset element 516 sets each of the query criteria 502 back to the original unfiltered status. 10044] When a user has defined his filter specifications, the user may select the filter activation element 514. Selecting the filter activation element sends a query command to the TAS 10 to select those trips or data from the data package 22 that meet the query criteria 502 selected by the user. The TAS receives the query command and returns the relevant data to the interface 500. Once the selected filters have been applied to the data package 22, the scenario definition interface 500 is updated to reflect the selected data.

(0045] One of the updates to the scenario definition interface 500 includes an update to the status box 520. The status box 520 displays information about the current status of the filtering process. The original trips in scenario box displays the total number of trips imported in the data package 22 that was specified by the user using the main menu interface 400. Generally, this number of trips will not change as the data package 22 is filtered. The static nature of this value is intended, as the original trips scenario box serves as a point of reference to indicate the size of the initial data package 22 prior to the application of data filters.

[0046] The status box 520 may further include a current trips box 522 which displays the number of trips remaining in the scenario after the filters selected by the user have been applied to the data package 22. The data in this box is dynamic, as each time the user changes the query criteria 502, the system will reconfigure the scenario data set and the current trips box 522 will be updated accordingly. The status box 520 may also include a filter status box 523 which indicates whether the user has applied filters, so that the user can easily determine whether the information reflects the initial data package or data that have already been filtered. In the example provided in Figure 5, the data package 22 has not yet been filtered. As a result, the value in the original trips box 521 (721 1) is the same as the value in the current trips box 522. The filter status box 523 also indicates that the data package is currently unfiltercd.

[0047J Once the user has selected and applied the initial filters to the data package 22, the TAS 10 may be configured to allow the user to further refine the data to model a specific scenario as desired. Figure 6 provides an example of a scenario viewer 600 which allows the user to define the scenario at an additional level of granularity by addressing the filtered data package 22 on a trip-by-trip basis. The scenario viewer 600 displays all trips from the data package 22 which match the query criteria 502 applied in the scenario definition interface 500. (0048] The scenario viewer interface 600 allows the user to exclude specific trips from the scenario. This functionality allows a user to exclude trips from the scenario that are not relevant to the business objectives of the scenario. The scenario viewer interface 600 may include a trip selection module 602 which allows the user to select the trips of interest. The included trip module 602 may include an included trip list 604. The included trip list 604 may be populated by all of the trips remaining in the scenario after the filters have been applied as described in relation to Figure 5 above. The data may be retrieved via an SQL query sent to the database server 16 by the TAS 10. The trip list may be include some or all of the fields of the trip table definition 300.

|0049] The user may further refine the trips included in the scenario by selecting one or more of the trips from the included trip module 604. Once the trips have been selected, they may be removed from the scenario by clicking the trip removal element 606. Upon clicking the trip removal element 606, trips will be removed from the included trip module 602 and placed into an excluded trip module 608. In some embodiments, the trip data fields displayed in the included trips module 604 may be different from trip data fields displayed in the excluded trips module 608. If a user wants to restore an excluded trip back into the scenario, the scenario view interface 600 may further include a trip restore element 610. The trip restore element 610 may work similarly to the trip removal element in that the user may select trips from the excluded trip module 608 and then select the trip restore element 610 to have the trips moved back into the included trips module 604.

[0050J Because the number of trips included in the scenario may still number in the thousands after filtering, the trip selection module 602 may further include various sorting controls 612 for sorting the data to allow a user to more easily identify and find trips for removal or restoration. The sorting module 612 may include a table selection control 614. The table selection control 614 may take the form of a radio control that allows the user to specify whether to sort the included trips module 604 or the excluded trips module 608. The sorting module 612 may further include one or more sorting controls 616. The sorting controls allow the user to specify which fields to sort by, and whether to sort them in ascending or descending order.

[00511 In some embodiments, the TAS 10 may allow users to specify certain types of trips of exclude from the analysis. In addition, the TAS may also be configured to allow the user to create trips for consideration and analysis. By way of example and not of limitation, the scenario viewer interface 600 may include an action options module 620 that gives the user this functionality. The action options module 620 may include overnight trips menu button 622. which allows the user to filter out overnight trips for selection. The action options module 620 may further include a new trip button 624 which will allow the user to access a user interface for creating new trips to add to the scenario. The new trip option may be useful in that it allows analysis of entirely new transportation options.

[0052] Once the user has finished selecting the trips they wish to include in the analysis performed by the TAS 10, the user may select the finalize scenario button 618 which will cause the selected trips to be stored in the system as the working scenario. Upon defining the trips to include in the scenario, the TAS may be further configured to provide an interface for defining facility groups for the scenario. A facility group, as used herein, is a grouping of one or more facilities based on some attribute of the facilities. In one embodiment, the attribute may be a geographical proximity of the facilities. In other embodiments, other attributes may be used, including facility types, facility capabilities (e.g., the types of cargo it can handle) or some other attribute.

[0053] Referring now to Figure 7, an example of a facility group management interface 700 is provided. The facility group management interface 700 may be used to create and define facility groupings which enable the TAS 10 to more effectively analyze the transportation network by considering trip consolidation opportunities between facility groups rather than just between pairs of individual facilities. For example, there might be a trip that currently transports cargo from a facility in the north side of Chicago to a facility in south Phoenix. There may also exist another defined trip that transports cargo from the south side of Chicago to a facility in north Phoenix. If each trip typically has a vehicle utilization rate of 20%, and they have roughly similar departure and arrival times, then cost savings may be realized by consolidating the trips into a single trip. The consolidated trip would begin at the north Chicago facility and then stop at the south Chicago facility to pick up the remainder of its cargo. The vehicle could then travel to Phoenix where it would first stop at the north Phoenix facility and then the south Phoenix facility to unload its cargo.

[0054] The. facility group management interface 700 includes a facility grouping module 702 which includes various display elements that allow users to define and create facility groups which may help to achieve the types of network savings described above. A facility grouping type selection element 704 allows the user to either build or define a new facility grouping, or to work with an existing grouping. In the embodiment shown the facility grouping type selection element 704 takes the form of a radio button control on the facility group management interface 700. If the user selects the "Build New Facility Grouping" option, the tolerance definition module 706 becomes active while the facility grouping import control 708 is inactive. If the user selects the "Work with an Existing Facility Grouping" option, the tolerance definition module 706 is inactive and the facility grouping import control 708 is active.

[0055] As noted previously, in some embodiments, facility groups may be defined according to a geographic proximity of facilities to each other. In determining whether to consolidate trips, it may be desirable to group together facilities that are located in the same geographic proximity, so trips among groupings can be consolidated rather than just trips among individual facilities. The appropriate group size should have short distances among facilities within the group, relative to the distances among groups. Thus, the facility grouping interface allows for the definition of facility groupings to have certain tolerance levels. A facility grouping tolerance level relates to the amount of geographical distance between facilities that may be grouped together in a facility grouping. A large tolerance allows facilities that have large distances between them to be grouped together. Thus, the large tolerance will result in fewer facility groups. Conversely, the tighter the tolerance, the smaller the permitted distance between facilities in the same group. As a result, a tight tolerance level will result in more facility groups with fewer facilities in each group.

[0056] The tolerance definition module 706 provides the user the ability to specify a tolerance level for the groupings generating by the TAS 10. The following table is an example of a how tolerance levels may be defined within the TAS 10.

10057] Upon selecting a desired tolerance level from the tolerance definition module 706, the user may then select the "Auto Create Facility Grouping Button." Selecting this button may result in the TAS 10 creating facility groups based on the defined tolerance level. In one embodiment, the facility groupings may be created by utilizing zip codes of the various facilities as an approximation of their relative distance to one another. For example, facilities with identical zip codes may be placed in the same facility grouping for each tolerance category except the "Self category (the "Self category requires that each facility be in its own group). Facilities sharing the first three digits of a zip code may not be placed in the same facility groups where the level is set to very tight, but they may be placed together where the facility level is set to tight, moderately tight, or large. These calculations may be generally performed by the TAS on the selected and filtered data package 22 via SQL queries against the data.

|0058] Once the user has selected the "Auto Create" button, the facility groupings created by the TAS 10 may be displayed in the facility grouping table 710. This table may be sorted by utilizing the sorting options 712 on the right side of the facility grouping interface 700. The facility grouping table 710 may include each facility in the scenario, and information about the facility group in which it has been placed. In one embodiment, the table 710 may provide a minimum, maximum, and average distance between the facilities that have been placed in the group.

[0059] In some embodiments, the user may be permitted to refine or alter the facility groups. This may be accomplished by renumbering the facility group column for a particular facility. For example, in the facility grouping table shown in Figure 7, a user may wish to place the San Jose P&DC and the San Francisco P&DC into the same facility grouping due to their relative proximity to each other. The user may change the facility group column for the San Jose P&DC to 656 so that it matches the facility group for the San Francisco P&DC. Alternatively, the user may create an entirely new facility group and assign both facilities to that group number.

J 0060) In order to facilitate the user in determining how to best group facilities, the facility grouping interface 700 is configured to provide easy access to information about each facility. Referring now to Figure 8, a facility viewer 800 is illustrated. The facility viewer 800 may be accessed by the user by selecting the lookup facility data butjon 722. The facility viewer 800 may include three interface components. The first component, the query parameter entry module 802, allows the user to enter specific parameters which allow for the TAS 10 to retrieve facility data relevant to the user. The user may specify an area 804, a state 806, and/or a zip code 808. Once the user has specified their query parameters, the user may click on the query execution control 810, which causes the TAS to query, select, and return the facilities stored in the data package 22 based on the parameters provided. The facility codes of facilities meeting the query parameters may be displayed in the query results element. To access the remaining details about each of the returned facilities, the user may select the facility code of the facility which results in the relevant facility data for that facility code being displayed in the facility data display 814. In some embodiments, this data is merely for informational and viewing purposes. In other embodiments, the user may be able to modify the facility data. Once the user is satisfied with the facility groupings as displayed in Figure 7, the user may finalize the facility grouping by selecting the finalize button 718. Additional processing options 720 may also be available, such as grouping validation, saving the grouping, or exporting the grouping to some common file format (such as a spreadsheet, for example).

(0061] After finalizing the facility groupings, the TAS 10 may be configured to advance the user to a direct trip lock down interface. The direct trip lock down interface provides a way for users to lock down direct trips so that they cannot be consolidated or eliminated in the scenario model. As noted above, the TAS 10 may be configured to analyze a scenario within the transportation network, and provide advice on trips that may be eliminated in order to improve efficiency within the transportation network. In some instances, there may be certain direct trips which cannot be eliminated from the transportation network, if doing so would improve efficiency. In order to exclude these trips from the TAS analysis, the direct trip lock down interface 900 allows the user to select trips so that they are not candidates for consolidation or elimination. Although a locked down trip may not be eligible for elimination, in some embodiments, other trips may be consolidated onto a locked down trip in order to leverage excess capacity on the locked down trip.

[0062] Referring now to Figure 9, an example of a direct trip lock down interface 900 is provided. When the user accesses the direct trip lock down interface 900, the TAS 10 may execute a query on the data package to return each of the direct trips in the scenario. These trips may be presented to the user in the fully adjustable direct trips table 902. The fully adjustable direct trips table 902 includes those trips which can be modified in any way desired during the optimizing process. The user may sort the direct trips listed in the fully adjustable direct trips table 902 by utilizing the sorting options 904 in a manner as described above in connection with the sorting options 612 as described in Figure 6 above. The user may then select the trips that they wish to lock down, and then click on the lock down trips button 906. The selected trips will then be moved from the fully adjustable direct trips table 902 to the locked down trips table 908. Trips included in the locked down trips table 908 may be flagged as being locked down in the scenario database. Locked down trips may also be restored to their original fully adjustable state by selecting the locked down trip in the locked down trip table 908 and then actuating the unlock trips control 910.

[0063] Once the user has locked down the necessary direct trips and otherwise finalized the scenario trip data, the data must be validated as being in proper form for analysis by the TAS 10. The TAS may be configured to validate data by running verification queries against the selected scenario trip data to ensure that all necessary data fields have appropriate values in them. Figure 10 illustrates an example of a data validation interface 1000 which may be used to validate the selected scenario data prior to running optimization routines and analysis, and to correct or modify the data where correction or modification is necessary.

[0064] When the user initially accesses the data validation interface 1000, an initial validation routine is run against the trips that have been included in the scenario. As noted above, the validation routine may be a query against the data package 22 which identifies missing values in required data fields or values which are not in the proper format for the data field. Once the initial validation routine has been run, the results may be displayed in the data validation results table 1002. The data validation results table 1002 displays missing or improperly formatted data values that must be corrected before the scenario can be analyzed by the TAS 10. In order to correct the missing or improperly formatted data values, a data editing table 1004 is provided. The data editing table 1004 initially displays all trips included in the scenario. The data validation interface 1000 may also include a table of excluded trips 1006 which lists all trips in the data package 22 which have been excluded from the scenario. The list of excluded trips 1006 along with the trip removal 1008 and trip restore 1010 buttons allows the user an additional opportunity to further refine the scenario without having to return to previous steps. |0065] When the initial validation returns its results and displays them in the data validation results table, the user may select one of the variables from the data validation results table 1002, a variable which has been returned as being invalid in some way. Upon selection of the variable, the data editing table 1004 may be configured to automatically sort its values by the selected variable. Alternatively, the user may select the variable header in the data editing table 1004, which will also sort trips included in the table by the selected variable. In the example provided in Figure 10, the user has selected the CONTPERTRUCK variable in the data validation results table 1002, which indicates that there are 35 trips that are missing this information in the currently defined scenario. The data in the data editing table 1004 has been sorted by the CONTPERTRUCK field, and thus the trips missing values for this field have been moved to the top of the list for adjustment and editing by the user.

[0066] Once the trips having missing data have been identified, the missing data may be ascertained by the user and added to the trips data via the data editing table 1004. In some instances, the user may not be able to ascertain the appropriate values for the missing data. In these instances, the user may have the option to remove the selected trip from the scenario. The user may proceed with the same routine and address each of the variables listed in the data validation results table 1002, and then the user may rerun the data validation by selecting "Validate Scenario Data" from the processing options 1012 located at the bottom of the data editing interface 1000. At this point, the validation routine is rerun. If no data validation issues are identified, the data validation results table 1002 will be returned as empty, and the user may proceed by clicking on the finish data editing button 1014.

[0067] Once the scenario data has been validated, the scenario data is in a form to be analyzed and optimized by the TAS 10. Although the optimization itself is a largely automated process, in some embodiments, the user may be provided the ability to specify certain details about the optimization prior to the TAS running the optimization routines. Referring now to Figure 1 1 , an example of an optimization configuration interface 1 100 for defining and setting parameters for the scenario optimization is provided. The configuration interface 1100 may include a data parameters box 1 102 which includes various controls and display elements that allow the user to specify specific parameters for analysis. The data parameters box 1 102 may include an estimated implementation date 1 104 which allows the user to specify the intended date for implemented changes recommended by the optimization process. This information allows the TAS 10 to better calculate costs related to the consolidation of trips. For example, if a trip is contracted to an outside vendor, and there is a penalty in the contract for an early cancellation of the trip contract, the implementation date 1104 may bear on the cost savings that may be achieved by cancelling the trip contract or consolidating the trip with another trip.

[0068] The configuration interface 1100 may also include a level of precision control 1 106. The level of precision control 1106 allows the user to specify the level of precision within the model created by the optimization routines of TAS 10. In one embodiment, the user may specify the precision in terms of the number of decimal points that will be used by the TAS 10 when performing calculations. The number of decimal points used may primarily impact the way that vehicle utilization is calculated in regards to the containers loaded onto the vehicle. Although a higher number of decimal place precision will generally result in the system identifying greater cost savings opportunities within the transportation network, utilizing the higher decimal place precision may not always be desirable.

J0069J By way of example and not of limitation, if the user specifies two decimal place precision within the model, the TAS 10 may calculate a modification to the network which may split containers loaded onto vehicles into fractional containers which may be as small as .01 containers in the extreme case. Such a modification might be difficult to implement in practice. Moreover, a two decimal place precision may cause the TAS 10 to consider so many scenarios for optimization that the performance of the TAS may become exceedingly slow due to the number of possibilities that are modeled. Selecting a 0 or 1 decimal place precision value, on the other hand, may not achieve the desired level of cost-saving opportunity identification. However, this setting may provide implementation recommendations which are more feasible and suitable for implementation.

|0070] The configuration interface 1100 may also include a split loads selection module 1 108. The split loads selection module 1 108 allows the user to specify whether or not to allow the optimization routine applied by the TAS 10 to split loads of cargo between trips. For example, if the TAS 10 is configured by the configuration interface 1100 to allow split loads, a current trip may be consolidated into multiple other trips. In contrast, if the TAS is configured not to allow split loads, a current trip may only be consolidated into a single other trip.

10071] The configuration interface 1 100 may also include optimization parameters 1 1 10. The optimization parameters 1 110 allow the user to adjust how the TAS 10 conducts its optimization. In one embodiment, utilizing the optimization parameters 1 1 10 allows the user to reduce the run-time for larger scenarios that are not resolved in a reasonable amount of time if the level is set at 100 percent. The optimization parameters 1110 also allow the user to specify whether displacement should occur during the model run-time. Displacement occurs when an optimization model moves cargo from one trip to a second trip, in order to move a third trip's volume onto the first trip. Although displacement may be desirable from an overall savings perspective because it allows a trip consolidation that may not otherwise be possible, it also may increase the complexity of the optimization, and the increase in time necessary for the TAS 10 to complete the optimization may outweigh the benefit provided by allowing displacement,

10072] Once the user has specified the parameters for the optimization, the TAS 10 may receive the scenario data and perform its optimization routines on the defined scenario. The TAS 10 receives the input scenario and runs the optimization model on the data. The optimization model in the TAS 10, which may be part of the analysis servers 18, may be a mixed integer program. In one embodiment, the mixed integer program may be solved utilizing optimization software such as ILOG CPLEX model. Other optimization software programs may be used, including IDSC, Prophesy, LoadCaptain, or some other software that is capable of receiving the scenario data. The optimization model may be defined according to various business rules which allow the software to effectively analyze the transportation network and minimize the total transportation cost of the defined scenario. These rules may include requiring that all cargo be delivered from its specified origin to its specified destination. The rules may further require that the operational capabilities of the vehicles in the transportation network not be exceeded by the proposed optimization. In addition, vehicle departure schedules must not be optimized in such a way that a departure is scheduled for a time prior to the time at which any of the designated cargo is available for transport. Vehicle arrivals must also take place prior to the time the cargo is required to be delivered at its destination. Depending on the level of optimality specified by the user, the TAS 10 considers some or all routing and scheduling options that meet the business rules and requirements discussed above, and identifies an optimal set of trips for the scenario along with the cargo that should be included with each trip in the scenario.

[0073] Once the TAS 10 has performed the optimization, the results of the optimization may be displayed to the user. Figures 12A-12D provide an example of a results summary interface 1200 that provides the user with relevant information about the model-run results. The results summary interface 1200 may include a scenario information tab 1202 which displays general information about the scenario that was created by the user. The information may include general information 1204 related to the scenario data that was used by the TAS 10 in analyzing the scenario. The scenario information tab may also include a table of trips included in the scenario (pre- optimization) 1206 which allows the user to point of reference that indicates the actual trip information that was modeled by the TAS 10.

J0074] Referring now to Figure 12B, an operational summary tab 1208 is provided. The operational summary tab 1208 displays information related to the scenario that was defined from the imported data package 22. The operational summary tab 1208 may include a general trip summary element 1210 which provides information about the trips included in the summary. In the example provided, the general trip summary element 1210 includes data relating to the total number of trips included in the data package 22, the number of trips excluded from the scenario by the user, the number of trips excluded from optimization due to other reasons, the number of trips actually included in the optimization that was run by the TAS 10, and the number of direct and multi-stop trips, respectively. A visual graph such as a pie chart, for example, may be provided to give a better sense of the data.

[0075] The operational summary tab 1208 may also include a model run summary element 1212 which displays data relating to the results of the optimization. In particular, the model run summary element 1212 may include information relating to the number of trips included in the optimization. The model run summary element 1212 may also include data about the number of trips that were adjusted by the model run, including the number of trips recommended for elimination, the number of trips with cargo added, and the number of trips with volume subtracted. As with the general trip summary element 1210, the data may be displayed in a graph format such as a pie chart. 100761 Referring now to Figure 12C an example of a utilization summary tab 1214 is provided. The utilization summary tab 1214 provides a concise summary of the utilization levels of the scenario prior to optimization and subsequent to optimization. Thus, the user may easily ascertain what type utilization efficiencies may be gained by implementing the recommended model. The utilization data may be presented in a utilization information element 1216. The utilization information element 1216 may include the original average vehicle utilization for direct, multi-stop, and all trips, respectively. In order to better understand or visualize the benefits of implementing the recommended model, the potential average utilization for the optimized scenario is also displayed to the user. The trip count information element 1218 provides additional information about the trips in the scenario that have not been eliminated by the optimization. The trip count information element may also provide a visual representation of this information in the form of a pie chart as shown.

[0077] Referring now to Figure 12D, the results summary interface 1200 may also include a cost summary tab 1220. The cost summary tab 1220 may include information related to the potential cost savings that may be achieved through the implementation of the recommended scenario. The cost summary tab may include a cost estimate element 1222 and an indemnity information element 1224. The cost estimate element 1222 may include information related to the cost of the scenario over time such as the pre-optimization costs of the direct trips in the scenario, the post-optimization cost of the direct trips in the scenario, and the difference between them. In addition, because the consolidation or elimination of trips may have indemnity (i.e., cancellation) costs associated with them, the indemnity information element 1224 provides an estimate of these costs and displays them as well. As noted previously, trips in the data package 22 may be performed under a contract with an outside contractor. Thus, cancellation of the trip may trigger an indemnity clause in the contract. The indemnity cost is typically based on how much time of the contract remains at the time of cancellation. For example, if a trip contract is cancelled in the early years, the indemnity costs will typically be greater than if canceled in the later years. Each of the display tabs described in Figures 12A-12D may include a results generation button 1226. When the user clicks this button, all of the data displayed in the results summary 1200 may be exported to a spreadsheet or comma delimited format for viewing in some other software application. 10078] Once the user has reviewed the results summary, the TAS 10 application may be configured to present to the user the operational details of the optimized scenario. Figures 13A-13C provide an example of an operational detail interface 1300. The operational detail interface displays the information about the recommended model in a way that allows the user to analyze the specific model recommendations for trip elimination or consolidation. In addition, the information provided may allow the user to assess the impact of the model on individual facilities and trips so that the feasibility of the model may be adequately assessed.

(0079] Referring now to Figure 13A₃ the operational detail interface 1300 may include a decision support workspace tab 1302. The decision support workspace tab 1302 may include a results table 1304 which displays the model results at the operational level. The results table 1304 includes a listing of each direct trip that is included in the optimization. The route identifier and the trip identifier may be displayed in the left most columns, In one embodiment, the remaining columns in the results table 1304 may be used to illustrate the differences between the trips as originally constituted in the data package 22, and the proposed recommendations for the scenario. In one embodiment, the information may be color-coded. For example, the information pertaining to the existing direct trips included in the optimization may be highlighted in blue, while the model recommendations may display the same columns (with the results from the optimization recommendations) highlighted in yellow. Thus, the results table 1304 may include operational level results that indicate for each existing trip how the model recommends that the cargo for that trip be transported in order to minimize costs by consolidating trips.

[0080] In some embodiments, the results table 1304 may be filtered to allow the user to more easily find targeted information in a larger table. The decision support workspace 1302 may provide a filtering module 1306 which allows the user to filter the data in the table. The filtering module 1306 may provide various filtering options. One filtering option allows the user to filter for round-trip or one-way results. The user may also filter the table data for only results where the existing trip has been recommended for elimination by the model. Another filtering option is to filter the data based on the type of result. In particular, the filter module 1306 may provide a type of trip adjustment filter. This filter may include options such as filtering trips that have been eliminated and consolidated onto a direct trip. The filter may further include an option to filter those trips that have been eliminated and consolidated onto a multi-stop trip. Other filtering options may also be provided such as filter based on facilities, routes, or some other criteria.

[0081] In some instances, the user may wish to assess the overall arrival and departure profiles of the optimized transportation network as it pertains to individual facilities. Referring now to Figure 13B, an example of a facility departure/arrival tab 1308 is provided. The facility departure/arrival tab 1308 may include a facility departure workspace 1310 and a facility arrival workspace 1312. Each of the facility departure workspace 1310 and the facility arrivals workspace 1312 includes a selection window 1314 that lists each of the facilities that have an associated departure/arrival in the recommended model. The user may select the desired facility to filter the display table.

{0082] The operation detail interface 1300 may also include a volume assignment tab 1316. The volume assignment tab 1316 provides information about the differences in cargo volume on between trips as currently constituted and as proposed by the optimization model. The volume assignment tab 1316 may include a volume table which includes all trips that the optimization selected to transport cargo within the transportation network. The data may be organized by the trip identifier and the leg identifier. In some embodiments, the table may include the origin facility for the trip/leg, the destination facility for the trip/leg, the original volume (i.e., utilization level) of the trip prior to optimization, and the adjusted volume after the optimization. The volume assignment table may also provide filtering capabilities which allow the user to analyze specific routes or trips.

J0083] Although the TAS 10 may provide significant guidance on how to optimize the modeled scenario with respect to the transportation network, there may be instances where the user, due to operational constraints, business rules, or some other reason, may wish to implement less than all of the recommended changes in the scenario. In addition, the user may also wish to further refine the recommended model by adding user-defined scenario modifications. In order to address these issues, the TAS 10 may be configured to include a model recommendation manager as provided in Figure 14.

[0084] The model recommendation manager 1400 provides an interface which allows the user to document that actual recommendation that the user intends to implement in the network. The model recommendation manager includes a table of model recommendations 1402 which may be similar to the results table 1304 in the decision support workspace 1302 described above. The model recommendation manager 1400 may also include an implementation table 1404 which lists the trips selected by the user to be implemented in the transportation network. The model recommendation manager 1400 allows the user to select the trips from the table of model recommendations 1402 and add them to the implementation table 1404 by clicking on the "Accept Selected Trips" button. Conversely, trips may be removed from the implementation table 1404 by selecting the trip that is to be removed and then clicking the "Reject Selected Trips" button. In one embodiment, the implementation table 1404 may be fully editable by the user, including the ability to add new recommendations. This allows the user to revise the recommendations to reflect desired modifications. Once the user has finalized the contents of the implementation table 1404, the recommendation may be exported to a detailed report format that may be used in other software applications such as spreadsheets, relational databases, or the like.

[0085] Using the above described systems, interfaces, and modules, a user can select targeted and limited portions of a transportation network to optimize those portions and achieve greater efficiencies within the network. Referring now to Figure 15, a flowchart describing a method for optimizing the transportation network is provided. At block 1500, the TAS 10 receives transportation network data. The data may include data such as a trip table defined according to the trip table definition 300 provided in Figure 3. At block 1502, the TAS 10 preprocesses the data to place the data into memory. Next the TAS 10 creates a user interface on the client computer 11 and presents a user-selectable option for defining the scope of the analysis. The user-selectable option may be provided in a user interface module such as the scenario definition module 500 described above in relation to Figure 5. Next, at block 1506, the TAS 10 receives a user input selecting a first level of specificity. Proceeding to block 1507, if the first level of specificity includes an area (such as, for example, one selected from the area filter 504), at block 1508, the TAS 10 provides an option for a second level of specificity that includes defining whether trips are wholly contained or not wholly contained in the selected area. If the first level of specificity does not include an area, the second option may not be provided as shown at block 1510.

]0086] In other embodiments, the system may provide recommendations for optimizing the transportation network that are assisted by the creation of facility groups. Figure 16 is a flowchart describing such an embodiment. At block 1600, the TAS 10 may receive data about the transportation network. Next, at block 1602, the TAS 10 may present a user selectable option for specifying or defining a facility grouping tolerance. In one embodiment, the user selectable option may be included in a tolerance definition module 706 as discussed in relation to Figure 7. Next at block 1604, the user selects one of the tolerance levels, and the TAS 10 groups the facilities according to the selected tolerance level at block 1606.

[0087] Figure 17 illustrates yet another embodiment in which the system consolidates trips in the transportation network. At block 1700, the TAS receives the transportation network data. Next, at block 1702, an interface module that allows the user to lock down certain trips is provided such as the interface described, for example, in Figure 9 above. Next, once the user has selected trips for lock down, the TAS 10 moves to block 1704 and analyzes the remaining trips (i.e., those eligible for consolidation) in order to determine recommended trip consolidations. Next, at block 1706, the TAS modifies the data by consolidating trips that are eligible for consolidation.

[0088] In yet another embodiment, a method for optimizing a transportation network is described by reference to Figure 18. According to the method, at block 1800, the system receives a first transportation routing solution. This solution may take the form of trip data defined as shown in Figure 3 above. Next, one or more trips are selected for consolidation at block 1802, and as a result of the consolidation, an improved transportation network is provided at block 1804. Next, at block 1806, the differences between the first routing solution and the second routing solution may be displayed to the user. In one embodiment, these differences may be shown in a decision support workspace 1302 as shown in Figure 13 above. At block 1808, a selection interface for selecting differences between the two solutions is provided. Next, at block 1810, an input to the selection interface selecting some, but not all of the differences is received in TAS 10. Based on the selected differences, the TAS 10 creates a third transportation routing solution at block 1812 which may be a modification of the first routing solution that incorporates the selected differences, but does not incorporate other aspects of the second routing solution.

|0089] It will be understood by those of skill in the art that numerous and various modifications can be made without departing from the spirit of the present invention. Therefore, it should be clearly understood that the forms of the invention are illustrative only and are not intended to limit the scope of the invention.

Claims

WHAT IS CLAIMED IS:

1. A computer-implemented method of identifying transportation routing solutions in a transportation network, the transportation network including routes and facilities, the method comprising: receiving data relating to the transportation network for analysis, the data including routes and schedules; preprocessing the data using statistical analysis software; presenting a first user-selectable option for defining a scope of analysis at a first level of specificity, the first level of specificity comprising the routes related to one or more components comprising a specified area, a specified facility, and a specified route; receiving an input indicating a selection of the one or more components within the first level of specificity; and presenting a second user-selectable option for defining the scope of analysis at a second level of specificity if the received input includes a specified area, the second level of specificity comprising an indication that the routes are wholly contained or not wholly contained within the specified area.

2. The computer-implemented method of Claim 1, further comprising receiving an input selecting the second level of specificity.

3. The computer-implemented method of Claim 1, wherein the specified area is a region.

4. The computer-implemented method of Claim 1 , wherein the specified area is a state.

5. The computer implemented method of Claim 2, wherein the received data further includes trips.

6. The computer-implemented method of Claim 5, further comprising: in response to receiving the input selecting the second level of specificity, selecting trips from the received data that correspond to scope of analysis indicated by the first and second levels of specificity.

7. The computer-implemented method of Claim 5, further comprising displaying the selected trips in a first table element.

8. The computer-implemented method of Claim 7, allowing a user to exclude a trip displayed in the first table element from the scope of analysis by selecting the trip.

9. The computer-implemented method of Claim 2, further comprising presenting a third user selectable option for defining the scope of analysis at a third level of specificity.

10. The computer-implemented method of Claim 9, wherein the third level of specificity is a route.

1 1. The computer-implemented method of Claim 9, wherein the third level of specificity is a facility.

12. A computer-implemented method of identifying transportation routing solutions in a transportation network, the transportation network including routes and facilities, the method comprising: receiving data relating to the transportation network for analysis, the data including one or more facilities; and producing a facility grouping based on one or more attributes of the facilities, said producing comprising: presenting a user-selectable option for defining a facility grouping tolerance the tolerance being related to the one or more attributes; receiving input indicating the selected facility grouping tolerance; and placing, based on the selected facility grouping tolerance, one or more of the facilities into a facility group.

13. The computer-implemented method of Claim 12, wherein the one or more attributes of the facilities comprises a geographical proximity among the facilities.

14. The computer-implemented method of Claim 13, wherein the one or more attributes of the facilities comprises a numerical limitation on the number of facilities in the grouping.

15. The computer-implemented method of Claim 12, wherein one of the facility attributes is a zip code.

16. The computer implemented method of Claim 15, wherein placing one or more of the facilities into a facility group comprises: selecting a first facility having a zip code attribute; comparing the zip code attribute to other zip code attributes of other facilities; grouping the facilities having similar zip code attributes in a facility grouping with the first selected facility.

17. A computer-implemented method of identifying transportation routing solutions in a transportation network, the transportation network including trips, routes and facilities, the method comprising: receiving data relating to the trips, the trips each including an origin facility and a destination facility; providing a user-selectable option for locking down one or more of the plurality of trips, the locked down trips being ineligible for consolidation; identifying one or more of the plurality of trips eligible for consolidation, the identifying being based at least in part on the received data and the locked down trips; and modifying the received data in accordance with the identified trips.

18. The computer-implemented method of Claim 17, wherein the locked down trips are direct trips.

19. The computer-implemented method of Claim 17, wherein the locked down trips are multi-stop trips. 70

20. The computer-implemented method of Claim 17, wherein identifying trips eligible for consolidation includes solving a mixed integer problem using optimization software supplemented by statistical analysis software.

21. A computer-implemented method of identifying transportation routing solutions in a transportation network, the transportation network including routes and facilities, the method comprising: receiving data relating to the transportation network for analysis, the data comprising a first transportation routing solution including route data, schedule data, and facility data; identifying one or more of the plurality of trips for consolidation, the identifying being based at least in part on the received data; determining, based on the identified trips a second transportation routing solution; displaying differences between the first transportation routing solution and the second transportation routing solution; providing a selection interface indicating at least one or more differences between the first transportation routing solution and the second transportation routing solution; receiving an input selecting some but not all of the differences; and re-determining, based on the selected differences, a third transportation solution.

22. The computer-implemented method of Claim 21, wherein the determining comprises solving a mixed integer problem, the mixed integer problem including as variables at least some of the received data.

23. The computer-implemented method of Claim 22, wherein the solving of the mixed integer problem is performed by an optimization software module.

24. The computer-implemented method of Claim 23, wherein the mixed integer problem is created based on business rules of the transportation network.

25. The computer-implemented method of Claim 24, wherein the business rules include requiring that cargo in the transportation network be delivered from a specified origin of the cargo to a specified destination of the cargo.

26. The computer-implemented method of Claim 24, wherein the business rules relate to operational capabilities of vehicles in the transportation network.

27. The computer-implemented method of Claim 24, wherein the business rules require that trip departures associated with the transportation network occur only after cargo designated for the trip is made available for transport, and the business rules further require that trip arrivals associated with the transportation network occur only before cargo designated for the trip is required at the destination.

28. A computer-readable medium having computer-executable instructions stored thereon which, when executed, cause a computing device to perform a method of identifying transportation routing solutions in a transportation network, the transportation network including routes and facilities, the method comprising: receiving data relating to the transportation network for analysis, the data including trips, routes and schedules; preprocessing the data using statistical analysis software; presenting a first user-selectable option for defining a scope of analysis at a first level of specificity, the first level of specificity comprising the routes related to one or more components comprising a specified area, a specified facility, and a specified route; receiving an input indicating a selection of the one or more components within the first level of specificity; and presenting a second user-selectable option for defining the scope of analysis at a second level of specificity if the received input includes a specified area, the second level of specificity comprising an indication that the routes are wholly contained or not wholly contained within the specified area.

29. The computer-readable medium of Claim 28, further comprising receiving an input selecting the second level of specificity.

30. The computer-readable medium of Claim 28, wherein the specified area is a region.

31. The computer-readable medium of Claim 28, wherein the specified area is a state.

32. The computer-readable medium of Claim 29, wherein in response to receiving the input selecting the second level of specificity, the method further comprises selecting trips from the received data that correspond to scope of analysis indicated by the first and second levels of specificity.

33. The computer-readable medium of Claim 32, further comprising displaying the selected trips in a first table element.

34. The computer-readable medium of Claim 33, allowing a user to exclude a trip displayed in the first table element from the scope of analysis by selecting the trip.

35. The computer-readable medium of Claim 29, further comprising presenting a third user selectable option for defining the scope of analysis at a third level of specificity.

36. The computer-readable medium of Claim 35, wherein the third level of specificity is a route.

37. The computer-readable medium of Claim 35, wherein the third level of specificity is a facility.

38. A computer- readable medium having computer-executable instructions stored thereon which, when executed, cause a computing device to perform a method of identifying transportation routing solutions in a transportation network, the transportation network including routes and facilities, the method comprising: receiving data relating to the transportation network for analysis, the data including one or more facilities; and producing a facility grouping based on one or more attributes of the facilities, said producing comprising: presenting a user-selectable option for defining a facility grouping tolerance the tolerance being related to the one or more attributes; receiving input indicating the selected facility grouping tolerance; and placing, based on the selected facility grouping tolerance, one or more of the facilities into a facility group.

39. The computer-readable medium of Claim 38, wherein the one or more attributes of the facilities comprises a geographical proximity among the facilities.

40. The computer-readable medium of Claim 39, wherein the one or more attributes of the facilities comprises a numerical limitation on the number of facilities in the grouping.

41. The computer-readable medium of Claim 38, wherein one of the facility attributes is a zip code.

42. The computer-readable medium of Claim 41, wherein placing one or more of the facilities into a facility group comprises: selecting a first facility having a zip code attribute; comparing the zip code attribute to other zip code attributes of other facilities; grouping the facilities having similar zip code attributes in a facility grouping with the first selected facility.

43. A computer-readable medium having computer-executable instructions stored thereon which, when executed, cause a computing device to perform a method of identifying transportation routing solutions in a transportation network, the transportation network including trips, routes and facilities, the method comprising: receiving data relating to the trips, routes, and facilities, the trips each including an origin facility and a destination facility; providing a user-selectable option for locking down one or more of the plurality of trips, the locked down trips being ineligible for consolidation; identifying one or more of the plurality of trips eligible for consolidation, the identifying being based at least in part on the received data and the locked down trips; and modifying the received data in accordance with the identified trips.

44. The computer-readable medium of Claim 43, wherein the locked down trips are direct trips.

45. The computer-readable medium of Claim 43, wherein the locked down trips are multi-stop trips.

46. The computer-readable medium of Claim 43, wherein identifying trips eligible for consolidation includes solving a mixed integer problem using statistical analysis software.

47. A computer-readable medium for identifying transportation routing solutions in a transportation network, the transportation network including routes and facilities, the method comprising: receiving data relating to the transportation network for analysis, the data comprising a first transportation routing solution including route data, schedule data, and facility data; identifying one or more of the plurality of trips for consolidation, the identifying being based at least in part on the received data; determining, based on the identified trips a second transportation routing solution; displaying differences between the first transportation routing solution and the second transportation routing solution; providing a selection interface indicating at least one or more differences between the first transportation routing solution and the second transportation routing solution; receiving an input selecting some but not all of the differences; and re-determining, based on the selected differences, a third transportation solution.

48. The computer-readable medium of Claim 47, wherein the determining comprises solving a mixed integer problem, the mixed integer problem including as variables at least some of the received data.

49. The computer-readable medium of Claim 48, wherein the solving of the mixed integer problem is performed by a statistical analysis software module.

50. The computer-readable medium of Claim 49, wherein the mixed integer problem is created based on business rules of the transportation network.

51. The computer-readable medium of Claim 50, wherein the business rules include requiring that cargo in the transportation network be delivered from a specified origin of the cargo to a specified destination of the cargo.

52. The computer-readable medium of Claim 50, wherein the business rules relate to operational capabilities of vehicles in the transportation network.

53. The computer-readable medium of Claim 50, wherein the business rules require that trip departures associated the transportation network occur only after cargo designated for the trip is made available for transport and the trip arrivals occur only before the cargo is required at the destination.

54. A system for identifying transportation routing solutions in a transportation network, the transportation network including trips, routes and facilities, the system comprising: means for receiving data relating to the trips, routes, and facilities, the trips each including an origin facility and a destination facility; means for providing a user-selectable option for locking down-one or more of the plurality of trips, the locked down trips being ineligible for consolidation; means for identifying one or more of the plurality of trips eligible for consolidation, the identifying being based at least in part on the received data and the locked down trips; and means for modifying the received data in accordance with the identified trips.

55. A system for identifying transportation routing solutions in a transportation network, the transportation network including routes and facilities, the system comprising: means for receiving data relating to the transportation network for analysis, the data including one or more facilities; and means for producing a facility grouping based on one or more attributes of the facilities.