System and method for managing the transport of freight

Description

TECHNICAL FIELD OF THE INVENTION

The present invention relates generally to freight systems and related logistical and information technology and, more particularly, to a system and method for managing the transport of freight.

BACKGROUND

In modern industry, goods are typically manufactured in one location and sold in another. Thus, goods must be transported from the manufacturing site to the final commercial outlet and are typically stored at intermediate distribution centers along the way. Transporting these goods from one location to another may require a substantial fleet of commercial carriers such as trucks. In such cases, fleet operators, who may or may not own some or all of the trucks in the fleet, must find a way to manage the fleet effectively. Otherwise, the participants in the distribution network may become dissatisfied. These participants may include those manufacturing the goods, those transporting the goods, those operating the distribution centers, and those operating the final commercial outlets.

Typical fleet operators include manual dispatchers at distribution centers who receive information about loads of goods that must be transported. This information may include the delivery date of each load, the origin of each load, the destination of each load, and other information associated with the loads. Manual dispatchers may also be aware of information associated with the trucks and the drivers of the trucks at their disposal. This information may include the capacity of each truck, the availability of each truck or driver, and the time that a particular driver or truck may have to transport a load of goods. Dispatchers often have no effective tools to match drivers and trucks with particular loads, and thus, they often match haphazardly and inefficiently. The haphazard and inefficient nature of matching may create dissatisfaction for the clients and drivers of a dispatcher's company.

Thus, many manual dispatchers often use a dispatching system to coordinate matching of drivers, trucks, and loads more efficiently. Dispatchers enter the information they receive about loads of goods and about trucks and drivers into the dispatching system. Having that information organized and available for review may allow dispatchers to satisfy the interests of clients and drivers more effectively. In addition, dispatchers may match drivers, trucks, and loads more efficiently.

A push for efficiency has also led to the creation and adoption of dynamic solvers in some fleet management systems. A typical dynamic solver receives all of the information about loads, trucks, and drivers. The dynamic solver then analyzes this information and generates a matching solution that maximizes yield. Many times, however, the dynamic solver does not match all of the loads with trucks and drivers because matching all of the loads does not offer an optimal solution. This result can be problematic when all loads must be transported. Another problematic aspect of dynamic solvers is their exclusive concern with efficiency and complete disregard for the various other interests in a distribution network.

SUMMARY

In accordance with the teachings of the present invention, a system and method for managing the transport of freight is provided. In a particular embodiment, a method for managing the transport of freight includes receiving information associated with at least a first plurality of loads and a second plurality of loads. In addition, the method includes applying at least one template to at least part of the information associated with at least the first plurality of loads, each template suggesting one or more preferred legs for at least one tour. The method also includes allowing a user, through a user interface, to accept one or more of the tours suggested by the at least one template. Additionally, the method includes allowing the user to manually create or modify one or more tours using at least part of the information associated with any loads that do not yet comprise an accepted tour.

Technical advantages of one or more embodiments of the present invention may include catering more closely to the various interests involved in transporting goods from one location to another. The interests in the transportation industry are more varied and multi-faceted than the one-dimensional focus on economic efficiency that is typically advanced. By having a toolset that can take into account these other interests in addition to economic efficiency, freight managers may manage the transport of freight more effectively.

Another technical advantage of particular embodiments of the present invention includes managing freight more effectively by forecasting legs of tours. Forecasting legs of tours allows for more effective tours to be created by increasing the number and type of legs that may be added to a tour. This may both increase the efficiency of the management system and lead to less carriers being stranded in a remote location at the end of a tour.

It will be understood that the various embodiments of the present invention may include some, all, or none of the enumerated technical advantages. In addition, other technical advantages of the present invention may be readily apparent to one skilled in the art from the figures, description and claims included herein.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and its features and advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:

FIG. 1 is a diagram illustrating an example freight distribution network;

FIG. 2 is a block diagram illustrating an example system for managing the transport of freight according to one embodiment of the present invention;

FIG. 3 is a flowchart of an example method of managing the transport of freight according to one embodiment of the present invention; and

FIG. 4 is a screen shot of an example user interface at a tour command center according to one embodiment of the present invention.

DETAILED DESCRIPTION

FIG. 1 is a diagram illustrating an example freight distribution network 10. In a typical freight distribution network, goods are manufactured at a factory or other manufacturing site, transported as freight to one or more distribution centers, and transported to one or more commercial outlets for sale. Distribution centers are typically located in different geographic regions and facilitate the transfer of goods from manufacturing sites to final commercial outlets.

Example freight distribution network 10 comprises distribution centers 20, commercial carriers 30, commercial outlets 40, and manufacturing sites 50. Distribution centers 20 may comprise any suitable distribution center operable to store goods manufactured at one or more manufacturing sites 50 and destined for one or more final commercial outlets 40. Distribution centers 20 may allow for loading of outbound goods onto commercial carriers 30 and for unloading of inbound goods from commercial carriers 30. It should be noted that, as used herein, outbound refers to the direction away from a distribution center, and inbound refers to the direction toward a distribution center. Distribution centers 20 may be arranged in any suitable manner, such as, for example, in different geographic regions (as in the illustrated example). Distribution centers 20 may be located relatively close to one or more commercial outlets 40 or manufacturing sites 50. One or more distribution centers 20 may alternatively be located relatively far from one or more commercial outlets or manufacturing sites 50. Any suitable number of commercial outlets 40 or manufacturing sites 50 may be associated in any suitable manner with one or more distribution centers 20 (and this may differ from that illustrated).

Commercial carriers 30 may comprise any suitable commercial carriers operable to transport freight, such as, for example, trucks, automobiles, airplanes, boats, ships, and/or trains. Commercial carrier operators may comprise any operator of a commercial carrier, such as, for example, the driver of a truck or automobile, the pilot of an airplane, the captain of a boat or ship, or the conductor of a train. Although much of the discussion below focuses on trucks and truck drivers, the discussion may apply to any suitable commercial carrier and commercial carrier operator. A commercial carrier 30 may be operable to receive freight (otherwise known as a “load”) at a manufacturing site 50 such as a factory and transport the load to one or more distribution centers 20 or directly to one or more commercial outlets 40. Commercial carriers 30 may be further operable to receive a load at a distribution center 20 and transport the load to one or more distribution centers 20 or to one or more commercial outlets 40.

Commercial carriers 30 may be owned and operated in any suitable manner. For example, one or more commercial carriers 30 may be associated with owner-operators. Additionally or alternatively, large numbers of commercial carriers 30 may be owned by a single entity. Operators of commercial carriers 30 may receive their route in any suitable location, such as, for example at a distribution center 20 or other field office. During periods in which loads are not being transported, such as, for example, during a commercial carrier operator's vacation, a commercial carrier 30 may be left by its operator in any suitable location, such as, for example, in a location proximate to a distribution center 30.

Commercial outlets 40 may comprise any suitable commercial outlets at which goods are sold to consumers. As examples only, commercial outlets 40 may include Walmart stores, Target stores, or any other suitable commercial outlet. The goods sold at commercial outlets 40 may originate at one or more manufacturing sites 50 and may be transported by one or more commercial carriers 30. Commercial outlets 40 may request regular shipments of goods at regular intervals. Alternatively, commercial outlets 40 may request shipments of goods without any predictability, such as, for example, if commercial outlets 40 order goods as actual inventory is sold (and the sale of actual inventory cannot be predicted accurately). In such cases, a relatively quick response time may be required to deliver the goods requested to commercial outlets 40.

Manufacturing sites 50 may comprise any suitable manufacturing sites or other sites that supply goods, such as, for example, factories. Manufacturing sites 50 may manufacture any suitable good, such as, for example, hardware items, soft items such as clothes, or food such as canned, dried, or refrigerated food. Alternative manufacturing sites 50 may not manufacture any good and may instead supply goods such as, for example, sand. The goods supplied by manufacturing sites 50 may eventually be sold at one or more commercial outlets 40 and may be transported by one or more commercial carriers 30. Manufacturing sites 50 typically deliver shipments to distribution centers 20 with regularity. However, manufacturing sites 50 may at times be required to make an urgent shipment, in which case a relatively quick response may be required to transport the goods. From the vantage point of distribution centers 20 coordinating routes for commercial carriers 30, commercial outlets 50 and manufacturing sites 50 may be examples of destination points for commercial carriers 30.

In operation, commercial carriers 30 may receive their routes (also known as “tours”) at a distribution center 20 or other suitable field office. A “tour” may generally be referred to as a route of one or more legs (each leg defined by an origin and a destination) on which a commercial carrier transports at least one load over at least one leg, each leg comprising any suitable number of stops, including no stops, between the origin and destination for the particular leg. Operators of commercial carriers 30 may transport loads according to the tour that each receives. In the illustrated example network, after receiving a tour, the driver of truck 30a may, on the first leg of the tour, transport a load from distribution center 20a to commercial outlet 40a, with possible delivery stops (not illustrated) in between. After delivering the remaining part of the load to distribution center 20a, the driver of truck 30a may then return to distribution center 20a. This is referred to as a “tour of one,” as the driver of truck 30a delivers only one outbound load before returning to distribution center 20a. Again, though not illustrated, it should be noted that transport of one load may consist of any suitable number of stops at one or more locations between the origin and destination of the load.

If the driver of truck 30a were traveling from distribution center 20a to manufacturing site 50a with no load on its first leg, were to receive a load from manufacturing site 50a, and then were to transport that load back to distribution center 20a, this tour would be referred to as a “deadhead.” A “deadhead” generally refers to tours with one load where the load is transported inbound to the distribution center.

The route of truck 30b in example network 10 illustrates a “tour of two.” Here, the driver of truck 30b may receive a load at distribution center 20b and transport and deliver the load to commercial outlet 40b, possibly two delivery stops, illustrated as points on the leg, at one or more locations in between. Again, it should be noted that any suitable number of delivery stops (where part of the load is delivered), including no stops, may be made on one leg between the origin and destination for the particular leg. Truck 30b may then travel to distribution center 20c, receive a load at distribution center 20c, and return and deliver the load to distribution center 20b. As may be observed, tours of any number of legs may be created, and managing loads effectively (or put another way, creating effective tours) becomes increasingly difficult and important as more distribution centers 20, commercial carriers 30, commercial outlets 40, and manufacturing sites 50 are involved in the system.

Modifications, additions, or omissions may be made to the distribution network 10 described without departing from the scope of the invention. The components of the distribution network 10 described may be integrated or separated according to particular needs. Moreover, the operations of the distribution network 10 described may be performed by more, fewer, or other components without departing from the scope of the invention.

Tours may be created to transport loads, and tours of numbers greater than one may be created to generate efficiencies. For example, it may be more efficient for commercial carrier 30b in FIG. 1 to travel to distribution center 20c after delivering its load to commercial outlet 40b if, for example, distribution center 20c is closer to commercial outlet 40b than it is to distribution center 20b. In fact, there may be many factors to consider when creating tours in order to generate maximum allocative efficiency. In addition, consideration of other important interests in addition to or in place of allocative efficiency may be required to operate an effective distribution network. Thus, a need exists for a system that considers efficiency and the myriad of other interests involved in a distribution network in creating tours and managing loads.

FIG. 2 is a block diagram illustrating an example system 100 for managing the transport of freight according to one embodiment of the present invention. Unlike typical systems, system 100 may offer a more effective solution to managing freight by better catering to the various interests involved in a distribution network in addition to considering the efficiency of the system. These interests may include, for example, those of manufacturers, commercial outlet operators, commercial carrier operators, and distribution center operators.

As an example only, at times, a manufacturer or commercial outlet operator may prefer to ship or receive goods according to a particular template. The value of having a tour according to the template may be greater to that party than the value of having a less expensive tour that does not follow the template. As used herein, a “template” generally refers to one or more preferred, additional legs for a particular tour. As discussed further below, there may be any suitable justification for a leg being preferred. For example, a manufacturer may have run a tour a certain way for a long time and does not want to exchange the stability and predictability of the route for another route that may be slightly less expensive. However, it should be noted that the template need not offer a more expensive tour per se.

In yet another example, a manufacturer or commercial operator may prefer a tour that does not violate a particular constraint. The value of having a tour that does not violate the constraint may be greater than the possibly lesser cost of a tour that does violate the constraint. As used herein, a “constraint” generally refers to a pre-determined condition that should not be violated when creating a tour. For example, a manager at a manufacturing site may disfavor allowing dead-head tours because dead-heads are perceived as being less efficient (by upper management, for example), even if dead-heads may be more efficient under particular circumstances. The manager may thus prefer tours that do not violate a dead-head constraint.

Templates or constraints may be catered to the interests of commercial carrier operators too. For example, commercial carrier operators may desire a template that specifies a pre-determined route, such as, for example, along a highway near an operator's home. Commercial carrier operators may also prefer to have tours that do not violate a constraint, such as a constraint limiting the number of hours a tour can last before the commercial carrier operator rests. Typical systems that focus solely on efficiency may not adequately take these factors into account and may thus produce less effective tours by increasing operator dissatisfaction.

Although templates and/or constraints may cater to interests other than that of efficiency, templates and/or constraints may, in particular circumstances, lead to more efficient tours being created. For example, templates may define multi-legged tours that experience indicates constitute very efficient tours. Thus, having a template for such a tour may save time by not requiring those creating tours to re-calculate efficiencies for each new set of unsolved loads, assuming that loads corresponding to the template legs are available. As another example, constraints may allow those creating tours to quickly determine if a tour they have created violates a state regulation, such as, for example, a limit on driving time for a commercial carrier operator.

System 100 of FIG. 2 comprises dispatch system 110, distribution centers 120, access point 130, network 140, data stores 150-170, tour command center 180, data stores 200-260, and dynamic optimizer system 270. Dispatch system 110 may comprise a dispatcher interface 112 through which dispatchers at distribution centers 120 or at any other suitable location, such as, for example, a field office, communicate with dispatch system 110. Distribution centers 120 may be the same as distribution centers 20 of FIG. 1, and thus, will not be described again. Dispatch system 110 may also comprise a commercial carrier operator interface 114 (in the trucking industry, a driver interface, for example) through which commercial carrier operators using access point 130 may communicate directly with dispatch system 110 over any suitable network 140. Network 140 may include, for example, the internet. Access point 130 may include any wireless or wireline communication device, such as, for example, a computer, a telephone, or a personal digital assistant, that a commercial carrier operator may access to communicate with dispatch system 110.

In particular embodiments, dispatch system 110 may be operable to receive information from dispatchers or commercial carrier operators themselves regarding power time availability (PTA) and store that information in data store 150. As used herein, “PTA information” may include, for example, any suitable information that identifies a commercial carrier's availability, such as, for example, the real-time location of the commercial carrier, the duration of a commercial carrier at a particular location, and the remaining time before the operator of the commercial carrier must stop for a regulatory-required rest.

Dispatch system 110 may also be operable to receive load information from any suitable source. For example, if dispatchers at distribution centers 120 or at other suitable field offices receive load information from a manufacturing site or commercial outlet (such as, for example, manufacturing sites 50 or commercial outlets 40, respectively, in FIG. 1), they may forward the load information to dispatcher system 110 which may then store that information in data store 160. Load information may include any suitable information associated with a particular load, such as, for example, characteristics of the goods that make up the load, the source of the load, and the destination(s) for the load.

Dispatch system 110 may also be operable to receive tour information from tour command center 180 and store that information in data store 170. Dispatch system 110 may be further operable to forward that information in, for example, a report format to dispatchers. Dispatchers may be located in distribution centers 120 or in any other suitable location such as a field office. Dispatch system 110 may forward the tour reports to the dispatchers through, for example, dispatcher interface 112. Additionally or alternatively, dispatch system 110 may forward the tour reports to commercial carrier operators directly, such as, for example, through operator interface 114.

Tour command center 180 may comprise a user interface 182, a constraint engine 184, a template engine 186, a forecasting engine 188, an optimizer interface 190, and a report engine 192. In particular embodiments, tour command center 180 may be operable to receive PTA and load information from dispatch system 110 and store that information in data stores 210 and 220, respectively. Tour command center 180 may be further operable to create tours based on the load and PTA information to satisfy some or all of the interests (described above) which may be involved in a distribution network. In alternative embodiments, tour command center 180 may be operable to receive load information and ignore any PTA information, store the load information in data store 220, and create tours based on the load information while ignoring any PTA information. It should be noted that tour command center 180 may be programmed using the Visual Net programming language, allowing for easy portability to the Internet and other networking capabilities.

User interface 182 of tour command center 180 may comprise any suitable interface operable to allow a user to communicate with tour command center 182 to create tours. Before a user may create tours through tour command center 180, however, tour command center 180 may also be operable to request user information from the user to authenticate the user and verify that the user is authorized to access tour command center 180. Information authorizing the user to access tour command center 180 may comprise, for example, a user name and password. User identification information may be stored as master data in data store 200, and tour command center 180 may access data store 200 to authorize a user to access tour command center 180. It should be noted that, in particular embodiments, more than one user may access tour command center 180 and create tours at one time, and each user may lock tours such that another user cannot create tours from the loads in the locked tours. In particular embodiments, each user may also lock unsolved loads such that another user cannot use those loads to create tours.

As described above, tour command center 180 may be operable to receive PTA information and loads information from dispatch system 110. Tour command center 180 may be operable to receive this information automatically in particular embodiments. In alternative embodiments, a user of tour command center 180, through user interface 182, may download the information to tour command center 180. In particular embodiments, a subset of all load information may be manually selected by a user and received by tour command center 180. However, before tour command center 180 receives the new PTA and loads information, one or more old tours, loads, and/or PTA information stored in tour command center 180 may be deleted in particular embodiments (either automatically or manually by the user). If information from previous sessions is not deleted, the new information that tour command center 180 receives from dispatch system 110 may modify and/or add to the existing information (such as, for example, modifying existing loads or adding new loads). After tour command center 180 receives the PTA and loads information, the PTA information may be stored in data store 210, and the load data may be stored in data store 220 as “unsolved loads.”

As mentioned above, in particular embodiments, tour command center 180 may ignore any PTA information. In such embodiments, an assumption may be made that there is unlimited power time availability at distribution centers 120. In particular embodiments, tour command center 180 may automatically make this assumption and create a tour of one for outbound loads and/or deadheads for inbound loads, storing the tour information in data store 260. In such embodiments, any remaining loads may continue to populate unsolved loads store 220. Tour command center 180 may then allow the user to pair (manually, using template engine 186, and/or using optimizer 270) the remaining loads with the created tours to add legs to the tours.

The assumption that there is unlimited power time availability may not reflect reality at times and may in fact provide an allocatively inefficient result if, for example, the number of tours does not match the power time availability at a particular distribution center. On the other hand, not ignoring any PTA information may offer several advantages. The first and most evident is that ignoring PTA information may provide for a simpler, and thus more manageable, system. Considering PTA information may increase the number of variables to be analyzed, adding to the complexity of the system.

A second, less evident advantage of not considering PTA information in creating tours is that, in such embodiments, particular tours need not be linked to particular commercial carriers. In other words, under the assumption of unlimited power time availability, a list of tours may be generated that is not linked to particular carriers, and this list may be presented to commercial carrier operators for the operators to choose which tour to accept. Operators need not be automatically assigned to a particular tour because it is the most efficient one based on their real-time PTA information. Thus, operators may choose a tour that best satisfies their preferences. These preferences may include, for example, the mileage they prefer to travel on a tour, the time they prefer to spend on a tour, or the schedule that allows them to attend a special event like a birthday or anniversary. Because many commercial carrier operators prefer to have a choice among several tours rather than be assigned the most empirically efficient tour, a system that assumes unlimited power time availability may be more effective and “operator-friendly” than one that considers PTA information, even if efficiency may not be greater.

In embodiments in which load and PTA information is received and stored by tour command center 180, the assumption about unlimited power time availability at distribution centers 120 need not be made. In these embodiments, tour command center 180 may automatically create, or a user may manually create, tours of one for outbound loads by matching PTA information with outbound load information. In particular embodiments, tour command center 180 may also automatically create, or the user may manually create, deadhead tours for inbound loads by matching PTA information with inbound load information. Legs associated with unsolved loads may then be added to these tours. Since their PTA information would be used to match their power to a more limited set of tours, commercial carrier operators may have less choice over which tours to take, and thus may not be as satisfied with the tours they receive. For example, a first commercial carrier waiting at a distribution center may be matched with the next tour received by the distribution center dispatcher (with the distribution center as the origin), even if a second commercial carrier on an inbound leg ten miles away from the distribution center would prefer to take that tour (and the first commercial carrier does not prefer that tour). Thus, although a system considering PTA information may be more economically efficient, it may ultimately be less effective.

Regardless of whether PTA information is considered in initially creating tours, tour command center 180 may comprise several tools to assist in generating effective tours. These tools may comprise constraint engine 184, template engine 186, forecasting engine 188, and optimizer interface 190. Constraint engine 184 may comprise any suitable engine operable to access, either automatically or after user input, the constraint definitions information in data store 230. Constraint definitions may comprise mandatory or default constraints on tour generation. Mandatory constraints may comprise constraints that a user may not override in creating tours, and default constraints may comprise constraints that a user may override in creating tours. Thus, for example, if a user seeks to create a tour that violates a state regulation, such as, for example, a regulation that limits how much time a driver may drive without rest, the tour may be flagged as violating a mandatory constraint, and the user may not be allowed to create such a tour. Other example mandatory constraints may include a constraint on having the second leg of a tour begin before the first leg of the tour ends, a constraint on pairing a refrigerated load and a non-refrigerated load on the same tour (to reduce the risk that a commercial carrier without refrigeration capabilities accepts the tour), or an operational constraint, such as, for example, creating a tour whose value is less than the cost of the tour. If, for example, a user seeks to create a tour that violates an unofficial company policy, such as, for example, a policy of not creating a tour whose final destination is far from the tour's origin, the tour may be flagged as violating a default constraint. In such a case, though the tour is flagged, the user may override the constraint and create the tour despite the violation. Alternatively, the user may need approval from the user's superior to override the default constraint. To override the default constraint, the user may either do so passively, such as, for example, by ignoring the flagged status of the tour, or actively, such as, for example, by removing the tour's flagged status in order to create the tour. Other default constraints may include, for example, a constraint on creating tours with dead-heads.

Template engine 186, which may also be referred to as a rule automation engine, may comprise any suitable engine operable to access the tour templates in data store 240, the unsolved loads (or a subset of unsolved loads) in data store 220, and the tours in tours store 260. A tour template may comprise any suitable template which, for a given tour, offers one or more preferred, additional legs for that tour. Thus, for example, assuming an origin and destination are identified by the user, say, for example, in a tour that has already been created and stored in tours store 260, template engine 186 may access tour templates data store 240 to find preferred leg(s) that may be added to that tour. Template engine 186 may access unsolved loads data store 220 to compare the preferred legs information in tour templates data store 240 with the unsolved loads available since the unsolved loads available may limit the preferred legs that may be added to a tour. Based on the unsolved loads and preferred legs information, template engine 186 may suggest one or more preferred legs that may be added to the tour. Template engine 186 may also identify the relative efficiencies of selecting one preferred leg over an alternative preferred leg if the tour template has two or more alternative preferred legs for one tour. Template engine 186 may also identify the relative efficiencies of selecting one load over another load to satisfy a particular preferred leg of a tour if more than one unsolved load would satisfy the particular leg. So, for example, the template engine may compare the parameters of the two loads, such as, for example, the waiting time associated with the two loads, to find the best load to satisfy the preferred leg of that particular tour.

After a user selects one or more preferred, additional legs for a first tour, the loads associated with those legs may be removed from further consideration by the template engine. Thus, the template engine may not consider these loads in suggesting preferred legs for any remaining tours, thereby possibly limiting the options available for adding preferred legs to these remaining tours. Considering only the remaining loads, the template engine may then recalculate preferred legs for any remaining tours. The user may choose one or more preferred legs (and associated loads) for a second tour, after which the associated loads are removed from further consideration by the template engine. This process may continue until all of the tours that the user sends to the template engine have been matched with loads that satisfy preferred legs for those tours (or until the user decides to end the process).

Tour templates stored in data store 240 may be based on any number of factors. For example, over time, a user of tour command center 180 may realize that for a particular origin and destination, the user always adds a particular leg to that tour (for example, if it is the most efficient leg to add). In that case, the user may create a tour template that identifies that leg as being a preferred leg for that particular origin and destination. Alternatively, a tour template identifying that leg as being a preferred leg for that particular origin and destination may be automatically created based on the same factors considered by the user, for example. Thus, template engine 186 and template data store 240 may offer a user a tool by which the user may more quickly and efficiently generate tours. In addition, by allowing the user to create templates (or for templates to be created automatically) based on any policy or rationale, the tool allows the user to consider interests in addition to efficiency, such as, for example, what may be preferred by manufacturers, commercial outlet operators, or commercial carrier operators.

Forecasting engine 188 may comprise another tool that a user of tour command center 180 may use to create more effective tours. A user may, at times, desire to create a tour with multiple legs where load data corresponding to one of the legs of the tour does not yet exist. For example, assume that a user desires to create a tour with a first load from A to B and a second load from B to C, where C is relatively distant from A. Because the user would prefer to avoid the inefficiencies and inconveniences of having the carrier travel back from C to A empty, the user may desire to include in the tour a leg from C to A or from relatively near C to A to reduce the miles that the carrier travels empty. At the time that the tour is being created, however, loads may only exist from A to B and from B to C, and no loads may yet exist at that time from C to A or from near C to A.

To resolve the dilemma, the user may access forecasting engine 188 to determine whether, though no loads exist from C or near C to A at the time that the tour is being created, there is a reasonable probability (based on a pre-defined constraint, for example) that a load will exist from C to A when the carrier reaches C. Forecasting engine 188 may be operable to make such a determination by accessing past load data store 250. Data store 250 comprises past load data that may identify, for example, the number of loads that have originated at a particular origin and that have been destined for a particular destination over a certain period of time. There may be other parameters associated with these loads, such as, for example, the day of the week or the day of the month that these loads were available for transport. Based on the parameters stored in past load data store 250, forecasting engine 188 may forecast the probable number of loads that will be available to satisfy the desired leg of the tour. Alternatively, the user herself may calculate the probable number of loads that will be available to satisfy the desired leg of the tour by looking at past load directly (and not by using forecasting engine 188). As used herein, “to forecast” generally refers to using past load data to predict whether a particular load associated with a particular leg will be available to transport at a particular time in the future.

Forecasting engine 188 may, in the situation above, predict, for example, that there will be ten loads available from C or near C to A based on past load data indicating that ten loads associated with that leg have been available every month (or, alternatively, every week) on the day (or, alternatively, the hour) in which the carrier is expected to arrive at C from B. Forecasting engine 188 may then access constraint definitions store 230 to assess whether the number of forecasted loads meets or exceeds a pre-defined, minimum threshold. If the threshold of forecasted loads that must be available for a particular leg is met, then a tour including the forecasted leg may be generated. If the threshold is not met, then a user may override the constraint if the constraint is a default constraint. Thus, if the threshold is met, forecasting engine 188 may indicate to the user that the user's proposed tour, including the forecasted leg, is reasonable and may be created. If, on the other hand, there are never (or rarely) any loads from C or near C to A and the threshold is not met, then forecasting engine 188 may indicate to the user that the user's proposed tour cannot reasonably include a forecasted leg from C or near C to A. In an alternative embodiment, forecasting engine 188 need not access constraint definitions store 230 and may simply present to the user a prediction of the number of loads that will be available at a particular time for a particular leg(s), and the user may decide if it is reasonable to add a forecasted leg to a tour based on this information.

It should be noted that, at any suitable time, information associated with current loads may be stored in past load data store 250 (to be used for forecasting legs of future tours). In particular embodiments, current load data may only be used for forecasting legs of tours created in future sessions. In alternative embodiments, current load data may be used for forecasting legs of tours currently being created. It should further be noted that although an available load from C to A at the time that the carrier arrives at C would be ideal in reducing empty mileage traveled, a user may also be interested in available loads from near C to A or from C to near A at the time that the carrier arrives at C. Although the carrier would travel some miles from C to near C empty (or, similarly, from near A to A empty), the load from near C to A may produce a more efficient and/or more effective tour. This may be the case if, for example, a forecasted load from near C to A produces less, total waiting time for a driver than a forecasted load from C to A, thereby decreasing the cost of the tour.

Forecasting engine 188 may allow a user to forecast legs of tours in order to create tours that are either more efficient or satisfy some other interest in the distribution network more effectively. It should be noted that, although the forecasted leg in the example tour above is from the final destination of the tour to the origin of the tour, forecasted legs may be used for any leg of a proposed tour. Forecasting may not be beneficial, however, with regard to the first leg of a tour since load data, it may be assumed, exists for the first leg. It should further be noted that forecasting engine 188 may make forecasting decisions based on past load data taken from any suitable period in the past. However, in particular embodiments, forecasting engine 188 may analyze only recent past load data, as older past load data may be outdated and may provide for less accurate predictions. For example, older past load data may provide for less accurate predictions if the demands of manufacturers or commercial outlet operators changes. It should further be noted that once a forecasted leg is added to a tour, the forecasted load associated with the forecasted leg may be taken into account if a user desires to create another tour with the same forecasted leg. Thus, for example, forecasting engine 188 may take into account that one of the forecasted loads has already been requested for another tour and may reduce the number of loads that it forecasts as available for the leg of the particular tour it is considering by one.

Access to dynamic optimizer system 270 through optimizer interface 190 offers yet another tool that a user of tour command center 180 may use to create more effective tours. Dynamic optimizer system 270 may comprise any suitable optimizer operable to receive load data and generate a tour solution that offers a maximum yield for the load data that it receives. In embodiments in which PTA information is also used to create tours, dynamic optimizer system 270 may be operable to receive PTA information and load information and create a maximum yield solution based on these factors. As described above, sending all load information received by tour command center 180 to dynamic optimizer system 270 may be undesirable because allocative efficiency may not be the only interest at play in the distribution network (and because optimizer 270 may not offer a solution for all of the loads). However, there may be times when a user desires to send a subset of the unsolved loads received from dispatch system 110 to dynamic optimizer system 270 to find the most efficient tour solution for that subset of loads. This may occur, for example, after the user has created tours manually and/or using the template engine, and a subset of unsolved loads remains for which the user desires to create optimally-efficient tours. Dynamic optimizer system 270 may be operable to receive the subset of loads and generate the most efficient tour solution for those loads, taking into account factors such as, for example, waiting time between legs of a tour and distance to be traveled. The most efficient tour solution may comprise the set of tours for the subset of loads with the least aggregate cost. The user may then select whether to accept or reject the tour solution generated by dynamic optimizer 270. If the user accepts the tour solution, the tours in the tour solution are stored in tours data store 260. It should be noted that in creating a tour solution, dynamic optimizer system 270 may be further operable to access past load data 250 to forecast legs in order to create an even more efficient tour solution (similarly to the manner in which forecasting engine 188 may access past load data 250 to forecast legs).

Report engine 192 of tour command center 180 may comprise any suitable engine operable to access tours data store 260, generate a report of the tours that have been created and stored, and send the report to dispatch system 110. Tours data store 260 may comprise the tours created and stored by a user during one or more sessions. These tours may have been created automatically, manually, using template engine 186, and/or using dynamic optimizer system 270. After a tour is stored in tours data store 260, a user may reconsider the particular tour and modify the tour or delete the tour from data store 260. A tour may be deleted, for example, if all loads in that particular tour are removed. After a user is satisfied with one or more of the tours in tours data store 260, the user may forward one or more of the tours to dispatch system 110. Alternatively, report engine 192 may automatically forward one or more of the tours to dispatch system 110. Report engine 192 may do so, for example, after the user logs out of tour command center 180. In particular embodiments, the tours in the tours report may be stored in tour data store 170. The user of tour command center 180 may be required to log into dispatch system 110 in particular embodiments to store the tours in the report in tour data store 170.

In operation, dispatch system 110 may receive, through dispatcher interface 112, load and PTA information from dispatchers at distribution centers 120 or at any other suitable location such as, for example, a field office. Dispatch system 110 may additionally or alternatively receive PTA information from commercial carrier operators themselves through, for example, communication device 130 over network 140. Dispatch system 110 may also additionally or alternatively receive load information from manufacturing sites or commercial outlets. After receiving PTA and load information, dispatch system 110 may store that information in data stores 150 and 160, respectively.

A user may access tour command center 180 through user interface 182. Tour command center 180 may authenticate the user and authorize access by comparing information received from the user with master data parameters. After the user logs on to tour command center 180, the user may prompt tour command center 180 to request, receive, and store the PTA and load data in data stores 210 and 220, respectively. Alternatively, tour command center 180 may request, receive, and store the PTA and load data automatically.

After PTA and load data is stored, the user may begin creating tours. Additionally or alternatively, tours of one may automatically be created for outbound loads and/or for inbound loads as dead-heads. The user may create or modify tours manually, which refers to manually pairing loads. Additionally or alternatively, the user may access template engine 186 to apply one or more templates to all or a subset of the loads. Additionally or alternatively, the user may access dynamic optimizer system 270 through optimizer interface 190 to receive a tour solution for one or more subsets of loads.

For particular tours, a leg of the tour may be forecasted. A user may use forecasting engine 188, past load data in store 250, and optionally constraint definitions in store 230 to add forecasted legs based on forecasted loads to tours created manually. Additionally or alternatively, forecasting engine 188 and past load data store 250 may be used in conjunction with template engine 186 to forecast legs of template tours. Additionally or alternatively, dynamic optimizer system 270 may forecast legs of tours using past load data in store 250.

For particular tours, the user may access constraint engine 184 to determine whether one or more constraint definitions stored in data store 230 may be violated by a particular tour. Additionally or alternatively, constraint engine 184 may automatically flag tours that violate constraint definitions in store 230. These definitions may be mandatory or default definitions. Tours that violate mandatory definitions may not be created. Tours that violate default definitions may be created if the default definitions are overridden by the user or by the user's superior for the particular tour (whether by passively overriding the default definition, such as by ignoring the flagged status of a tour, or by actively overriding the default definition, such as by removing an impediment to creating a tour).

Tours that are created may be stored in tours data store 260. If a user is dissatisfied with one or more tours in data store 260, the user may modify or delete those tours. After a user is satisfied with the tours in data store 260, the user may prompt report engine 192 to generate a report of the tours in data store 260 and to send the report to dispatch system 110. Alternatively, report engine 192 may automatically generate a report of the tours in data store 260 and send the report to dispatch system 110 (at the end of a user session, for example). At any suitable time, such as, for example, after the tours have been created, information associated with the loads comprising the tours may be stored in past load data store 250 to be used for forecasting legs of future tours.

After receiving the report of tours from tour command center 180, dispatch system 110 may store the tours in tour data store 170. Dispatch system 110 may communicate tour data to dispatchers at distribution centers 120 or at any other suitable field office through dispatcher interface 114. Alternatively, commercial carrier operators may access and accept available tours through interface 114 using a communication device 130 over a network 140. In this way, the transport of freight may be effectively managed in system 100.

Modifications, additions, or omissions may be made to the system 100 described without departing from the scope of the invention. The components of the system 100 described may be integrated or separated according to particular needs. Moreover, the operations of the system 100 described may be performed by more, fewer, or other components without departing from the scope of the present invention.

FIG. 3 is a flowchart of an example method 300 of managing the transport of freight according to one embodiment of the present invention. At step 310, the tour command center receives load data from the dispatch system. The tour command center may receive the load data from the dispatch system after it is prompted by a user of the tour command center. Alternatively, the tour command center may receive the load data automatically. The tour command center may store the load data in an “unsolved loads” data store after it receives the data. In particular embodiments, any PTA information may be ignored in creating tours. In these embodiments, unlimited power time availability may be assumed for outbound loads (and/or dead-head, inbound loads). In alternative embodiments, the tour command center may receive PTA data in addition to load data from the dispatch system.

At step 320, the actual process of creating tours begins. Tours may initially be created automatically by the tour command center. For example, the tour command center may automatically create tours of one for outbound loads and/or inbound loads. Additionally or alternatively, the user of the tour command center may decide whether to create tours from the unsolved loads manually (at step 320a), using a template (at step 320b), or using an optimizer (at step 320c). FIG. 4, described further below, is a screen shot of an example user interface at the tour command center. FIG. 4 illustrates how a user may create tours manually, using a template, or using an optimizer in one embodiment.

A user may decide to use one or more of the three methods to create tours. For example, a user may create tours manually (at step 330) for two or more of the unsolved loads. The user may also apply the tour templates to a subset of the unsolved loads (at step 340) and accept one or more of the tours suggested using the templates (at step 350). The user may also run the optimizer for a subset of unsolved loads to generate a tour solution for those loads (at step 360) and accept or reject the tour solution (at step 370). Any remaining unsolved loads may be reconsidered through any of the three methods. It should be noted that mandatory and/or default constraints may be applied, automatically or after a prompt by a user, to any created tour. It should further be noted that legs of tours may be forecasted, based on, for example, past load data and a constraint, in creating tours using one or more of the three methods.

The generated tours are stored at step 380. At step 390, a report of the tours is created either automatically or after a prompt by a user. At step 400, the report is sent to the dispatch system. At step 410, the dispatch system stores the tours and distributes them to dispatchers located at distribution centers or other suitable field offices for distribution to commercial carrier operators. Additionally or alternatively, the dispatch system may distribute the tours to commercial carrier operators themselves over a network such as the Internet. The transportation of freight may thus be managed effectively.

Modifications, additions, or omissions may be made to the method 300 described without departing from the scope of the invention. The components of the method 300 described may be integrated or separated according to particular needs. Moreover, the operations of the method 300 described may be performed by more, fewer, or other components without departing from the scope of the present invention.

FIG. 4 is a screen shot of an example user interface 500 at a tour command center according to one embodiment of the present invention. The example user interface comprises an infeasible (or “unsolved”) load section 510, a tours list section 520, a highlighted tour section 530, a template engine button 540, a dynamic optimizer button 550, and a history button 560. It should be noted that the screen shot may not capture some of the information displayed at the tour command center, and described below, that would be accessed by using the illustrated scroll bars.

Infeasible load section 510 comprises the unsolved loads downloaded from the dispatch system that have not yet been assigned to any tour. The header of section 510 identifies the total number of unsolved loads displayed and provides a drop-down menu that allows a user to filter the loads by their division. A division refers to the geographic area associated with a load. The header also provides a “Show only Unlocked” check box that a user may select to display only those loads that have not been locked and are available for tour creation or tour modification. The remainder of section 510 provides detailed information associated with each unsolved load, and the information is organized into multiple fields.

The fields in infeasible loads section 510 include a pro number field (which identifies a unique ID number associated with each unsolved load that the tour command center automatically generates and that may not be modified), an equipment type field (which identifies the type of load being transported such as, for example, a refrigerated load or a dry load), a type of load field (which identifies the load's direction, whether inbound or outbound), a load division field (which identifies the geographic area associated with a load), a reference number field (which identifies whether a load is scheduled for live or drop loading), an origin code field (which identifies the code for a load's origin), an origin city field (which identifies the city and state of a load's origin), a destination code field (which identifies the code for a load's destination), a destination city field (which identifies the city and state of a load's destination), an arrival time field (which identifies a load's early arrival date and the time of the load's last stop), and a load identification field (which identifies the customer load identification reference number for a load). Another field, not illustrated, may be a stops field which identifies the number of stops for a particular load. It should be noted that a user may modify particular information associated with the unsolved loads. In addition, a user may sort the information in the fields in any suitable manner.

In addition to fields, section 510 may include command buttons for a user to select for particular purposes. Command buttons may include, for example, a button to lock a load (so that other users may not access the load, for example), a button to display detailed stop information for a particular load, a button to display a map of the load itinerary, and a button to display a window showing the total miles, total out of route miles, and/or estimated time of arrival if the selected load is added to a pre-selected tour(s). Another command button may include a button to move a load to a tour in tours list section 520 and a button to add a new tour to tours list section 520 comprising the selected load.

Tours list section 520 comprises the tours that have already been created. These tours may be modified by adding or removing legs, deleted, or locked so that other users cannot access the loads comprising the locked tour to create another tour. The header of section 520 identifies the total number of tours displayed and provides drop-down menus that allow a user to filter the tours by their first origin or by their division. The header also provides a “Show only Unlocked” check box that a user may select to display only those tours that have not been locked. The header additionally provides a button to modify the display of section 530. The remainder of section 520 provides detailed information associated with each tour, and the information is organized into multiple fields.

The fields in tours list section 520 include a tour identification field (which identifies a unique number associated with each tour that the tour command center automatically generates and that may not be modified), an equipment type field (which identifies the type of loads being transported in the tour), a first pro number field (which identifies a unique ID number associated with the first load in the tour), a first origin field (which identifies the city and state associated with the first load in the tour), an origin date field (which identifies the early departure date for the first load in the tour), a last destination field (which identifies the city and state of the last stop associated with the last load in the tour), a destination date field (which identifies the early arrival date for the last stop associated with the last load in the tour), a first load field (which identifies the customer load identification reference number for the first load in the tour), a load field (which identifies the number of loads in the tour), and a type field (which identifies the direction, outbound or inbound, of the first load in the tour).

Tours list section 520 also includes fields comprising checkboxes. Some boxes are checked automatically to alert a user that a tour satisfies a pre-determined condition. For example, a tour that comprises more than one load is automatically flagged as “paired.” A tour that violates a constraint may also be automatically flagged. These constraints may include a “no dead-head” constraint which identifies a tour with one load where the direction is inbound, a “no date discrepancy” constraint which identifies paired loads where the first load arrives at its destination after the second load on the tour must depart, or a “no stranding” or “destination” constraint which identifies a tour where an operator is left stranded at the end of the tour because the origin of the first load is not the same as the last stop destination of the last load of the tour. If a tour violates a default constraint, the box flagging the constraint violation may be unchecked by the user or by or with the permission of the user's superior to override the warning.

Tours list section 520 also includes command buttons for a user to select for particular purposes. For example, a user may lock a tour by selecting the “locked” button beside each tour. Once locked, other users may not access the load(s) comprising the locked tour to create other tours. However, other users may access these loads if the user unlocks the tour by deselecting the “locked” button.

Highlighted tour section 530 comprises a detailed description of a tour in tours list section 520 that has been selected. The header of section 530 provides the tour identification number of the selected tour, the early departure time of the first stop in the selected tour, the early arrival time of the last stop in the tour, the total miles for the tour, the total out of route miles for the tour, the total hours for the tour, and the estimated time of arrival of the tour. Section 530 also provides a cost button, which, when selected, opens a window displaying the tour cost, the wait time cost, the dead head cost, and the outbound cost. The remainder of section 530 provides detailed information associated with each load in the tour, and the information is organized into multiple fields.

The fields in section 530 include a pro number field, a sequence number field (which identifies the sequence of the loads in the tour), an equipment type field, a type of load field (inbound or outbound), a load division field, a departure date field, a reference number field, an origin code field, an origin city field, a destination code field, a destination city field, an arrival time field, a load identification field, a stops field, a loaded “L” miles field (which identifies the number of loaded miles for the load), an “hours to next pick-up” field (which identifies the time between the early arrival of the previous load and the early departure of the current load), and an empty “M” miles field (which identifies the number of empty miles for the load). It should be noted that particular information associated with a load displayed in highlighted tour section 530 may be modified by a user.

In addition to fields, section 530 may include command buttons for a user to select for particular purposes. Command buttons may include, for example, a “change division” button that allows a user to change the division of a load, a “map” button that opens a map window with the load itinerary, a “displays stops” button that opens a window that displays detailed stop information, and a “remove load” button that removes a selected load from a tour. It should be noted that, after a load is removed from a tour, the load may become an unsolved load in section 510. Furthermore, after the load is removed from the tour, one or more of the tour's parameters (appearing in sections 520 and 530) may be recalculated to reflect the removal of the load.

Template engine button 540 may be selected by a user to send all or a subset of the unsolved loads to a template engine, such as, for example, the template engine described above with reference to FIG. 2. Dynamic optimizer button 550 may be selected by a user to send all or a subset of the unsolved loads to a dynamic solver, such as, for example, the dynamic optimizer described above with reference to FIG. 2. It should be noted that although template engine button 540 and dynamic optimizer button 550 may be located in infeasible loads section 510 (as illustrated), these buttons may alternatively be placed in any other suitable window, such as, for example, a separate window that also displays a report button (which may generate a report of the tours created and send the report to the dispatch system). History button 560 may be selected by a user to display past load data in order for the user to forecast legs for a tour. In alternative embodiments, history button 560 may access a forecasting engine that may forecast a particular load for a particular leg and determine whether the leg may be added to a tour, returning the result to the user.

In operation, a user accessing tour command center user interface 500 may analyze the loads in infeasible load section 510 for the purpose of creating effective tours. The user may create tours from these loads manually, using the template engine (via button 540), and/or using the dynamic optimizer (via button 550). The user may further select the history button to facilitate forecasting of legs. The tours created may populate tours list section 520. After one or more tours are created, the user may select a particular tour in tours list section 520. After the user selects the tour, the tour may be displayed in highlighted tour section 530, allowing the user to evaluate the tour more closely. Tour command center interface 500 may thus allow a user to quickly and easily create and evaluate tours. After evaluating the created tours, the user may open a window displaying a report button, select that button, and send the created tours to the dispatch system.

Modifications, additions, or omissions may be made to the user interface 500 described without departing from the scope of the invention. The components of the user interface 500 described may be integrated or separated according to particular needs. Moreover, the operations of the user interface 500 described may be performed by more, fewer, or other components without departing from the scope of the present invention.

Although the present invention has been described with several embodiments, various changes and modifications may be suggested to one skilled in the art. It is intended that the present invention encompass such changes and modifications as fall within the scope of the appended claims.