Patent Description:
The present invention relates to the field of freight, shipping, and dock management; more particularly, to an automated cross-dock management system, method, and/or apparatus; even more particularly, to an optimized and automated cross-dock management system, method, and/or apparatus for use with less-than-truckload carriers.

Within the shipping industry exists a segment of transportation that focuses on less-than-truckload (LTL) freight loads, which can vary from a single item to a nearly full truckload. To transport freight originating from a common origin destined for multiple locations around the country or region, LTL carriers often employ a hub-and-spoke network of terminals.

Once freight is picked up, it is brought back to a facility where it is transferred across a dock (a process commonly referred to as "cross-docking"). This process typically involves manually unloading the load (or portion thereof) from one trailer and loading it onto another. An system for improving cross-dock operations is described in <CIT>.

In recent years, there have been many improvements in warehouse operations. Specifically, large e-commerce retailers and shipping services have begun to use automated guided vehicles (AGVs) to move freight around warehouses. Typically, these AGVs are lower-cost devices that are designed to move freight placed upon them from a first location to a second location in the warehouse. These AGVs use a simple navigation method using markers and have basic collision sensors to avoid bumping into other AGVs.

However, these AGVs are typically not suited for cross-dock operations, especially in an LTL environment. First, in a cross-dock operation, an AGV may need to convey an entire movable platform (MP) which can weigh up to <NUM>,<NUM> pounds (or more). AGVs currently being used in most warehouses can typically only convey a few hundred pounds at most. Further, most current AGVs can only move in a grid-like pattern whereas cross-dock operations require much more advanced collision avoidance systems because manual workers may also be present.

Additionally, as will be described later, the AGVs may need to perform a variety of functions such as moving MPs, moving decks, and/or moving individual pieces of freight. Current AGVs and cross-dock systems are not equipped to handle and/or calculate these types of moves. What is needed is a cross-dock management system capable of effectively using AGVs to supplement or entirely replace manual moves in a cross-dock environment. Such a cross-dock system must be highly adaptable to handle exceptions, such as AGV recharging or maintenance, and should enable cross-dock operations to be extended to operate <NUM> hours a day, seven days a week.

Document D1: <CIT> discloses a possibility of using automated guided vehicles (AGVs) to move movable platforms (MPs) around a dock and to navigate between particular specified MP positions.

The present invention provides an automated cross-dock management system configured to optimize moves on a cross-dock. The automated cross-dock management system uses inbound manifest data to calculate ordered move instructions for all inbound movable platforms, inbound modular decks, and inbound freight. The ordered move instructions can be assigned to be carried out by manual conveyance vehicles or by AGVs based upon a plurality of criteria. The automated cross-dock management system is also able to detect damaged freight on the cross-dock using a combination of video streams from video cameras.

These and other advantages of the present invention will be readily understood with the reference to the following specifications and attached drawings wherein:.

Preferred embodiments of the present invention will be described herein below with reference to the accompanying drawings. In the following description, well-known functions or constructions are not described in detail because they may obscure the invention in unnecessary detail. While the present invention is generally directed to LTL operations for use in the trucking industry, the teachings may be applied to other shipping industries, just as those by air, sea, and rail. Therefore, the teachings should not be constructed as being limited to only the trucking industry. For this disclosure, the following terms and definitions shall apply:.

" The embodiments described herein are not limiting, but rather are exemplary only. It should be understood that the described embodiments are not necessarily to be construed as preferred or advantageous over other embodiments. Moreover, the terms "embodiments of the invention," "embodiments," or "invention" do not require that all embodiments of the invention include the discussed feature, advantage, or mode of operation.

As noted above, LTL carriers typically transport freight originating from a common origin destined to many different locations around the country via a system of terminals. Typically, once freight is picked up, the freight is brought back to a facility where it is transferred across a dock <NUM> (cross-docked), which involves unloading the freight from one trailer and loading it onto another. Freight can move through one or more terminals <NUM> (e.g., small terminals or distribution centers) in a hub-and-spoke network until the freight reaches its destination terminal and/or is delivered.

In this present invention, freight may be received at its origin via one of several methods: loose pallets, boxes, cartons, crates, drums, barrels, or the like; by MP <NUM> with decks <NUM> (<FIG>), an <NUM>'x8' (or similarly sized) platform used for double or triple stacking of freight on a MP <NUM> by which cargo consisting of loose pallets, boxes, cartons, crates or the like are stacked upon going to either a single destination or multiple destinations; by single MP <NUM>, MP <NUM> without decks <NUM> as described in <CIT> by which decks <NUM> and cargo consisting of loose pallets, boxes, cartons, crates or the like are stacked upon going to either a single destination or multiple destinations; or by multiple MPs <NUM> such as in a full truckload, rail container, ocean container, or the like consisting of two or more MPs <NUM> going to either a single destination or multiple destinations.

In some embodiments, freight having non-standard dimensions may be combined and/or placed in standardized containers having known dimensions. Such standardized containers allow for easier moving of the freight either by a manual move or AGV move. The standardized containers primarily function to make the cargo "AGV-friendly" or "AGV-compatible.

Referring first to <FIG>, depicted is a typical terminal <NUM> used by current LTL carriers. As shown, dock <NUM> is long and narrow. Typically, dock <NUM> is <NUM> feet in width or less. An inbound door <NUM> of dock <NUM> is used for unloading trailers <NUM> and a second (outbound) door <NUM> is used for loading trailers <NUM>. Unloading is generally sequenced in a last in, first out (LIFO) process. Thus, pallets or parcels (freight <NUM>) in the nose (front) of the trailer <NUM> that need to be unloaded must first have the entire trailer <NUM> unloaded to provide access to the desired freight <NUM>. As a worker <NUM> cross-docks freight <NUM> from the inbound door <NUM> to the outbound door <NUM>, half of the time is typically spent without any load (i.e., empty carries), which wastes both time and money. Typically freight <NUM> is conveyed across dock <NUM> using a conveyance vehicle <NUM>, such as a forklift. The conveyance vehicle, as referred to herein, may be manually operated, remotely operated, or completely autonomous (AGV). Further, at least one load door is required for every load point, but multiple doors may be necessary for multiple schedules to the same load point. Since loading is generally sequenced from the nose to the rear, freight <NUM> is typically docked in a bay outside the door to allow for co-mingling of the freight <NUM> on the trailer <NUM> for the optimum load. This practice creates congestion, wasteful re-handling time, and additional cost. Also, because dock <NUM> is long and narrow, the maneuverability of workers <NUM> using conveyance vehicles <NUM> is severely limited, especially when there is a large quantity of freight <NUM> on dock <NUM>.

An optimized cross-dock management system <NUM> in accordance with a first embodiment of the present invention transforms the process for moving LTL freight across the dock <NUM> by adding a novel combination of mechanics, technology, and automation as depicted in <FIG>. To facilitate the optimized cross-dock management system <NUM>, an optimized dock <NUM> may be employed that is two to three times wider and two to three times shorter than a traditional dock; thus, an optimized dock <NUM> may more closely resemble a square or large rectangle. Designed properly, an optimized dock <NUM> may require one-third the number of doors as dock <NUM> without sacrificing capacity. Alternatively, the optimized dock can <NUM> be wide enough such that a predetermined number (e.g., <NUM> to <NUM>, more preferably <NUM> to <NUM>, most preferably, <NUM> to <NUM>) of MPs <NUM> can be spaced out per dock door. The distance between dock doors may be, for example, <NUM> feet or more. When a MP <NUM> is removed from a trailer <NUM> it can be conveyed onto the dock <NUM>.

Further, the use of MPs <NUM> allows for an entire trailer to be unloaded or loaded and conveyed in less than five minutes, thus increasing efficiency and saving money. MPs <NUM> may be used to provide optimized load building and planning via real-time data and sensing technology, such as barcodes (2D or 3D), radio-frequency identification (RFID) tags, three dimensional (3D) imaging, Bluetooth low energy (BLE), magnetics, sensor fusion, global positioning system (GPS) tracking, and the like. Preferably, the MP <NUM> has a height of <NUM>" or less.

The MP <NUM> may have removable side panels, walls, or other retraining materials, such as ropes, nets, and/or rods that contain, or otherwise restrain, loose pallets or shipment parcels placed thereon. When an enclosed MP <NUM> is employed (e.g., when walls, panels, or the like are used), the MP's shape is preferably a cube or a rectangular prism, but other shapes are anticipated to meet a specific need or trailer shape, such as a triangular prism or cylinder. A roof panel may also be employed with an enclosed MP <NUM>, but is not required. To facilitate movement, the MP <NUM> may employ a plurality of wheels, castors, or the like. To facilitate use with a forklift, the MP <NUM> may comprise cut outs (e.g., a rectangular notch), at the base of each side of the platform, that are configured to receive fork lift prongs from any directions. In certain aspects, the movable platform may even be powered (e.g., motorized). In certain aspects, for example, when an open air trailer is used, the MP <NUM> may be vertically removed from the trailer using, for example, a crane or other hoisting apparatus.

A sample MP <NUM> compatible with the present invention is depicted in <FIG> (side view) and 3B (perspective view). Features of this MP <NUM> is described in more detail in copending <CIT>, and <CIT>. Herein will be described the features of MP <NUM> that are relevant to the logistics of the present application. As shown, each MP <NUM> comprises a plurality of decks <NUM> which are placed upon vertical posts <NUM>. The height of each deck <NUM> can be adjusted using a conveyance vehicle <NUM> by inserting the tines of the conveyance vehicle <NUM> into slots <NUM> and moving the deck <NUM> to a different height on posts <NUM>. Each set of four vertical posts <NUM> can accommodate one or more decks <NUM>. However, it is preferably that each set of four posts <NUM> only accommodates a single deck <NUM> for simplicity of operations and to maximize the space available on MP <NUM> for freight <NUM>.

If three decks <NUM> are located on a single MP <NUM>, any freight <NUM> on the movable platform can be further identified by a section identifier A-F which identifies a more specific location of the freight <NUM> on the deck <NUM> of MP <NUM>. Further, the left and right sides of MP <NUM> may be assigned identifiers <NUM>, such as a color or other ID. Additionally, each post <NUM> on MP <NUM> may be assigned a readable tag <NUM>. Assigning this combination of sections A-F, identifiers <NUM>, and tags <NUM> allows a position on movable platform <NUM> or deck <NUM> to be specified with great accuracy. For example, a worker executing a move instruction, as will be described later, can be supplied with a section, a post location, and a side which specifies where freight <NUM> is to be placed on MP <NUM>. Additionally, the additional granularity provided by this additional identification information provides the necessary information for AGVs <NUM> to execute move instructions for MPs <NUM>, decks <NUM>, and/or freight <NUM> as will be described later.

For example, section B can be used to identify all freight located on top of the front most deck <NUM> above section A and in front of section D. Each section A-F specifies a location (front, center, rear) and a height (ground level or deck) on MP <NUM>. Further, each identifier <NUM> identifies a side of the MP <NUM> and each tag <NUM> identifies a specific post on the MP <NUM>.

As already stated, in some embodiments, the workers <NUM> may use conveyance vehicles to move the MPs <NUM> about dock <NUM>. Workers <NUM> may also be supplemented with AGVs <NUM>. Conveyance vehicles <NUM>, AGVs or otherwise, may include a forklift, towing or pushing vehicle, or other manipulating components, working alone or as a team. Further, each conveyance vehicle <NUM> may be supplied with remote control functionality allowing for local remote control, on dock <NUM>, or centralized remote control, which is performed at a monitoring facility. Remote control may be useful when moves need to be completed overnight (e.g., to handle a late arrival), allowing a single operator to perform moves from a monitoring facility for multiple terminals <NUM>. This allows terminals <NUM> to be active <NUM>/<NUM> without requiring a worker <NUM> at each facility.

As will be described in more detail later, instructions from instruction database <NUM> can be provided directly to the AGV <NUM> and the movement of the AGV <NUM> about dock <NUM> may be performed by following markers on (or wires in) the floor, or by other navigation sensor-based means, such as vision, magnets, lasers, GPS, infrared sensors, cameras, RFID array <NUM>, or any other known means. It should be obvious to one of ordinary skill in the art that the conveyance vehicles can be supplemented with or upgraded with future navigation technologies still in development.

In some embodiments, AGVs <NUM> may also be utilized to move decks <NUM> and/or freight <NUM> about dock <NUM> from a first MP <NUM> to a second MP <NUM>. By moving an entire deck <NUM> and the freight <NUM> thereon in a single move, what previously would have taken multiple moves can now be accomplished in a single move. In an automated system, the sector information about the deck <NUM>, the identifiers <NUM>, and the tags <NUM>, all of which are stored in the cross-dock management system <NUM>, can be utilized to assist in the move.

Preferably, the plurality of MPs <NUM> are the size of the bed of a typical pup trailer (e.g., <NUM>' in length, <NUM>" wide, <NUM>" tall). However, MPs <NUM> could also take on the form of other lengths, smaller or larger, as long as they fit inside a trailer <NUM>. For example two MPs <NUM>' in length could be deployed inside a pup trailer as well as three MPs <NUM>' in length. Any combination of MP lengths, larger or smaller can be combined to fit inside a trailer. It would also be implied that the combination of MPs <NUM>, large or small, can fit inside any sized trailer, larger or smaller than <NUM>'. This allows an entire trailer to be unloaded at once by simply removing MP <NUM> from the trailer <NUM>. After the MP <NUM> has been removed from a trailer <NUM>, it is conveyed to an assigned space <NUM> as will be described later. As depicted in <FIG>, the spaces <NUM> are arranged in a grid pattern which provides several advantages. First, because an entire trailer <NUM> can be unloaded quickly, the trailer <NUM> can quickly be removed from the unloading door <NUM>. Thus, many less unloading and loading doors are needed for cross-dock management system <NUM>. Also, MPs <NUM> which contain decks <NUM> or freight <NUM> that must be exchanged can be placed in spaces <NUM> next to each other which reduces the movement required of each conveyance vehicle <NUM>. And, each MP <NUM> can be accessed from all four sides which provides many more routes which reduces congestion (by providing more moving paths) and also allows multiple conveyance vehicles <NUM> to access the same MP <NUM> for simultaneous unloading and loading. MP <NUM> also makes irregular freight <NUM> easier to handle since it can be loaded onto the movable platform on dock <NUM> where there is much more room to maneuver than in the trailer <NUM>. Further, since a combination of different types of conveyance vehicles <NUM> can be utilized, this reduces the number of workers needed to man each dock <NUM>.

<FIG> depicts another embodiment of dock <NUM> in which spaces <NUM> are angled <NUM>-<NUM>° degrees with respect to the spaces <NUM> depicted in <FIG>. Some terminals <NUM> have support posts <NUM>, or other obstacles, spaced at regular intervals. These posts <NUM> may interfere with the grid of spaces <NUM> depicted in <FIG>. The angled spaces <NUM> facilitate a more efficient conveyance operation in terminals <NUM> with posts <NUM> by allowing the conveyance operator to pull straight through the dock <NUM> to drop off or pick-up the MP <NUM>. This can often be accomplished in one move. In the prior dock layout of <FIG>, parking an MP <NUM> was like parallel parking a car because posts <NUM> and MPs <NUM> had to be avoided. A conveyance vehicle <NUM> would require multiple backwards and forwards moves to get the MP <NUM> placed into the space <NUM>.

In <FIG>, the spaces <NUM> are shown using an outline showing where an MP <NUM> can be placed. The outline of spaces <NUM> may physically appear on the floor, which is needed to allow workers <NUM> to correctly position MPs <NUM>. However, in a terminal <NUM> where all MP moves are carried out by AGVs <NUM>, there is no need for the spaces to be shown on the ground because other navigation techniques, to be described later, can be utilized to place the MPs <NUM> into spaces <NUM>. In this scenario, the floor of terminal <NUM> can be reconfigured as needed. For example, if the number of MPs <NUM> on the floor is low, only a portion of terminal <NUM> may need to be used and MPs <NUM> may be confined to certain sections of terminal <NUM>. This "sectoring" allows other areas of the terminal <NUM> to be utilized for other purposes. For example, a first section of terminal <NUM> can be designated for MPs <NUM>, a second section could be used for storage, and a third section could be placed off-limits to AGVs <NUM>. This allows the floor-space of terminal <NUM> to be optimized for daily usage.

<FIG> depicts a system diagram showing the hardware and resources employed by cross-dock management system <NUM> used to optimize unloading and loading of trailers <NUM> and movement of MPs <NUM>, decks <NUM>, and freight <NUM> on dock <NUM>. First, input data <NUM> (e.g., manifests, arrivals) arrives at cross-dock management system <NUM> via a secure internet connection <NUM>. Input data <NUM> provides cross-dock management system <NUM> with the initial information needed to optimize the loading and unloading of trailers <NUM> as well as the conveyance of MPs <NUM>, decks <NUM>, and freight <NUM> across dock <NUM>. One of ordinary skill in the art would recognize that manifest data may include the number of inbound trailers <NUM>; number of inbound MPs <NUM>; number of inbound decks <NUM>; freight <NUM> dimensions and weight; origin and destination of each MP <NUM>, deck <NUM>, and piece of freight <NUM>; flags indicating if freight is AGV-compatible; etc..

The received input data <NUM> is stored in a local warehouse database <NUM> so that it can be utilized by initial setup optimization <NUM> to determine optimal instructions for the unloading and loading of MPs <NUM>. Specifically, the initial setup optimization <NUM> is a series of algorithms that utilizes the input data <NUM> to determine optimal instructions which minimize loading and unloading time; identify which freight <NUM>, decks <NUM>, and MPS <NUM> require movement and/or no movement; group common destination freight <NUM>, minimize MP <NUM>, deck <NUM>, and freight <NUM> movement time; reduce empty carries and moves; prioritize certain moves based on service and transit service requirements; reduce travel distance; and optimize the number of workers <NUM> and/or AGVs <NUM> required based upon the number of moves. Any of the instructions can manually be overridden by a supervisor or other worker <NUM> by utilizing supervisor/user interface <NUM>.

Once the instructions are determined, they are stored in instructions database <NUM>. The instructions are classified into two categories: AGV instructions and human instructions. This classification can be based on classification data included in the manifest (e.g., AGV-friendly freight <NUM>).

A first set of instructions specifies moves that can be carried out before daily shipments arrive such as conveyance, MP <NUM> placement, and/or any other moves which can be used to prepare dock <NUM> prior to arrival of trailers <NUM>. These moves could be carried out overnight by AGVs <NUM> or by remotely controlled conveyance vehicles <NUM>. A second set of instructions specifies where each arriving MP <NUM> is to be placed and what specific freight <NUM> or decks <NUM> need to be moved to/from each MP <NUM>.

The instructions specify in which space <NUM> each MP <NUM> is to be conveyed and what specific freight <NUM> or decks <NUM> need to be moved to/from each MP <NUM>. The instructions are provided to each worker on a tablet <NUM> wirelessly connected to the instructions database <NUM>. Tablet <NUM> may be any device having a display that is capable of receiving instructions from instruction database <NUM>. In a preferred embodiment, tablet <NUM> is a portable communications device with a touch screen and one or means for user input such as a keyboard, barcode reader, RFID reader, etc..

<FIG> depicts a sample instruction screen <NUM> that may be shown on tablet <NUM> providing an instruction to worker <NUM>. As shown, the upper section <NUM> of instruction screen <NUM> indicates the worker's name <NUM>. The upper section <NUM> may also indicate other actions that can be performed by worker <NUM>, such as next instruction button <NUM> which worker <NUM> may utilize to skip the currently shown instruction (e.g., worker detected freight damage). A left section of <NUM> of instruction screen <NUM> indicates a pickup location for the move. In the depicted example, the worker <NUM> is instructed to pick up freight from "Bay 2B" which specifies a particular space <NUM> on dock <NUM>.

The right section <NUM> provides the destination information for the freight <NUM>. As shown, the destination information indicates a destination space "Bay 10F. " Further, the right section <NUM> depicts a visual placement for the freight on movable platform <NUM> using MP visualization <NUM>. MP visualization <NUM> depicts a side view of MP <NUM> showing posts <NUM> and decks <NUM> in abstract. Essentially, MP visualization <NUM> depicts MP <NUM> using a similar view to that of <FIG> showing sections A-F. MP visualization <NUM> is further provided with a color to indicate which side (left/right) of MP <NUM> that freight <NUM> should be placed. MP visualization <NUM> also indicates which post <NUM> next to which freight <NUM> is to be placed. Thus, the final destination for freight <NUM> can easily be highlighted on MP visualization <NUM> by shading <NUM>. MP visualization <NUM> provides a simple interface which conveys a great deal of information to worker <NUM> quickly and efficiently. By viewing MP visualization <NUM>, a worker quickly knows which space <NUM>, deck <NUM>, and post <NUM> at which the freight <NUM> is to be placed. It should also be apparent that a similar MP visualization <NUM> can be provided to a worker <NUM> for picking up freight <NUM> in left section <NUM>.

The instructions sent to tablet <NUM> may also provide an optimized moving path (directions). The instructions provided on tablet <NUM> may also be supplemented by or replaced by augmented reality devices, such as head mounted displays (HMDs). For example, the tablet <NUM> may display instructions screen <NUM> while a HMD provides turn-by-turn instructions or augments the dock <NUM> with a moving path for worker <NUM>.

Also, the instructions may include moves for entire decks <NUM> and all the freight thereon if the freight is intended for the same destination. In some embodiments, the instruction may cause the tablet <NUM> to display additional information including shipment origin, priority moves, destination, weight, dimensions, departure time, due date, unload assignment movable platform dock location and shipment parcel location within the MP <NUM>, and load assignment movable platform dock location and shipment parcel location.

As each instruction (i.e., move) is performed by a worker <NUM> or an AGV <NUM>, a reader (RFID or barcode) attached to the tablet <NUM> may be used to verify each move. For example, before a move is completed, a worker <NUM> first scans the identifier (e.g., barcode, RFID tag) on freight <NUM> or deck <NUM> and scans the identifier on the MP <NUM> or deck <NUM>. Then, the worker conveys the freight <NUM> or deck <NUM> to its destination and scans the destination MP <NUM>, deck <NUM>, post <NUM> and/or freight <NUM> to verify that the move has been completed. For decks <NUM>, the provided instructions may also include a height of the originating deck <NUM> and the height at which the deck <NUM> is to be moved to on the destination movable platform <NUM>. Preferably, the heights at which decks <NUM> are placed on posts <NUM> are uniform on each MP <NUM> which allows all moves to be standardized at each dock <NUM>.

After a move, the worker <NUM> or AGV <NUM> is then supplied with the next instruction, preferably, based upon the previous destination in order to reduce overall travel distance. The next instruction may also be based on a priority of the instruction. It should be obvious to one of ordinary skill in the art that MPs <NUM>, decks <NUM>, posts <NUM>, and freight <NUM> can be labeled with any combination of identifiers such a barcodes, RFID tags, NFC tags, or any other machine readable code.

In some embodiments, each movable platform <NUM> is equipped with a collision avoidance system <NUM> which may include a camera, radar sensor, sonar sensor, etc. at a front end (i.e., opposite from the worker) of MP <NUM>. The collision avoidance system <NUM> can connect to the tablet <NUM> by a suitable wired or wireless connection such as Wi-Fi or Bluetooth. The collision avoidance system <NUM> allows a worker <NUM> to safely maneuver a MP <NUM> in and out of trailers <NUM> and across dock <NUM>. The collision avoidance system <NUM> may be provided with a light source to help the worker during the loading or unloading process.

Additional technologies including, but not limited to, temperature and vibration sensors, light sensors to determine if the trailer door is opened, weight sensors, obstacle detection as described in <CIT>, and a GPS or cellular device for tracking may also be equipped on the MP <NUM>.

As freight <NUM>, decks <NUM>, and MPs <NUM> are being moved around dock <NUM>, it is important to keep track of the location of everything so it does not end up at the wrong final destination. Equipping each worker <NUM> with a tablet <NUM> helps to ensure that each instruction is carried out properly. However, a worker <NUM> may still move freight <NUM> or deck <NUM> without scanning it properly. Thus, the cross-dock management system <NUM> may utilize other sensors as a backup to tablets <NUM> as will be described with reference again to <FIG>.

Such systems also enable AGVs <NUM> to be deployed instead of or in addition to workers, thus enabling cross-dock management system <NUM> to be fully automated, if needed. A first example of such a system that may be employed by cross-dock management system is RFID array <NUM> which preferably comprises a plurality of RFID readers arranged in a grid above dock <NUM>. Each of the RFID readers in RFID array <NUM> is coupled to an RFID server <NUM> which is capable of real-time tracking of each MP <NUM>, post <NUM>, deck <NUM>, piece of freight <NUM>, AGV <NUM>, and/or worker <NUM> located on dock <NUM>. The tracking information from RFID server <NUM> is periodically or constantly provided to a network server <NUM> which can be used by real time instruction algorithms <NUM> to verify that each instruction has been carried out properly. If the real time instruction algorithms <NUM> detect that any instructions have been carried out improperly or that MP <NUM>, post <NUM>, deck <NUM>, piece of freight <NUM>, AGV <NUM>, and/or worker <NUM> has moved to an incorrect location, the instructions database <NUM> can be corrected in real time to correct any errors. Further, if an incorrect or improper move is detected, an alert may be generated to notify appropriate personnel of the error. The incorrect moves can also be stored in the local warehouse database <NUM> to determine any trends or for later handling. This information could be used to monitor compliancy or malfunctioning AGVs <NUM>.

The RFID tags used in combination with the present invention can store data indicative of, for example, shipment origin, destination, weight, cube, groupings, AGV-compliancy, dimensions, number of shipment parcels, due date, etc. or may simply indicate a tracking number. The RFID tag and any associated RFID reader may be configured to work using one or more RFID technologies, including, without limitation: (<NUM>) a Passive Reader Active Tag (PRAT) system; (<NUM>) an Active Reader Passive Tag (ARPT) system has an active reader, which transmits interrogator signals and also receives authentication replies from passive tags; and (<NUM>) an Active Reader Active Tag (ARAT) system uses active tags awakened with an interrogator signal from the active reader. A PRAT system has a passive reader that only receives radio signals from active tags (e.g., battery operated, transmit only). The reception range of a PRAT system reader can be adjusted from <NUM>-<NUM>,<NUM> feet, allowing flexibility in applications such as asset protection and supervision. A variation of the ARAT system could also use a Battery-Assisted Passive (BAP) tag which operates like a passive tag, but has a small battery to power the tag's return reporting signal. For example, passive ultra-high frequency (UHF) RFID tags may be used to identify, locate and track items within the dock and/or yard. Suitable UHF RFID tags, and associated RFID readers,. While RFID is generally described herein, other technologies may be used in addition to, or in lieu of, RFID to facilitate tracking of the movable platforms and/or shipment parcel(s), such as near field communication ("NFC").

Cross-dock management system <NUM> may also include a video server <NUM> also in communication with network server <NUM>. A first function of video server <NUM> is security which is handled by security module <NUM>. Preferably, video server <NUM> is capable of receiving video feeds from each device on dock <NUM> equipped with a video camera. For example, dock <NUM> may be equipped with a standard security system found at most terminals <NUM> used for monitoring theft and facility access. The video feeds from one or more of the security cameras in the security system could be supplied to video server <NUM>. Other video sources may include video feeds from cameras mounted on conveyance vehicles or AGVs <NUM> (e.g., part of collision avoidance system <NUM>). And, as will be discussed later, video or camera information acquired by dimensioner array <NUM> may also be monitored by video server <NUM>.

Security module <NUM> may monitor all of the aforementioned described video feeds and detect movement to create alerts for security personnel. Further, each time an alert occurs, security module <NUM> may store the video associated with the event in video database <NUM>.

The various described video feeds may also be utilized to provide damage identification. A comparison damage module <NUM> may be utilized to detect damaged freight <NUM> by comparing each piece of imaged freight <NUM> to previous images of the same freight <NUM> acquired at an earlier point in time (e.g., earlier in the day, at another terminal <NUM>, at pickup, etc.) using a difference algorithm to determine changes in freight <NUM>. If any significant changes are detected in freight <NUM> (e.g., above a certain change threshold), the comparison damage module <NUM> generates an exception which triggers a review of the freight <NUM> by a supervisor or other personnel. As will be described in more detail later, all exceptions are stored and classified in exceptions database <NUM>.

The video feeds may also be monitored by a machine learning damage module <NUM>. Machine learning damage module <NUM> uses machine learning to detect damage in the video feeds. For example, the machine learning damage module <NUM> may initially be supplied with various examples of freight damage images. Artificial intelligence can then be utilized to categorize and generalize the initial input information to determine damage and generate exceptions. As exceptions are corroborated by human review, the AI of machine learning damage module <NUM> modifies its behavior appropriately. Over time, the machine learning damage module <NUM> becomes more sophisticated at detecting damage to freight <NUM> and would be capable of detecting damage in hard to image areas, such as on the top of MP <NUM> which is out of sight of workers <NUM>. Similarly, if any damage is detected by machine learning damage module <NUM>, an exception is generated which is stored in exceptions database <NUM> for further review.

The real time instruction algorithms <NUM> are able to handle any exceptions or other problems that may occur in real time. For example, the real time instruction algorithms <NUM> are provided with a supervisor or worker interface <NUM> which allows a supervisor to prioritize certain MPs <NUM> or freight <NUM>. If a supervisor receives a telephone call or communication indicating that certain freight <NUM> has been prioritized or must reach a new and different final destination, the supervisor can use worker interface <NUM> to provide this information to cross-dock management system <NUM>. The real time instruction algorithms <NUM> then computes an exception which is stored in exception database <NUM> and revised instructions are provided to instruction database <NUM>. In this manner, the workflow of workers <NUM> and AGVs <NUM> on dock <NUM> is not interrupted. The workers <NUM> and AGVs <NUM> are simply provided new and/or updated instructions to carry out.

Real time instruction algorithms <NUM> can also receive input from external real time data <NUM> such as weather, trailer delays, etc. For example, another terminal <NUM> may inform the cross-dock management system <NUM> of trailer delays or breakdowns. In another example, the real time instruction algorithms <NUM> may be notified of external real time data <NUM> including weather events or road closures which will affect either inbound and/or outbound trailers <NUM>.

Cross-dock management system <NUM> may also provide output data <NUM> to a shared network to other terminals <NUM>. In this manner, all of the cross-dock management systems <NUM> among the various terminals <NUM> are linked together. The sharing of output data <NUM> has many benefits. For example, if a certain geographical region has been hit by a natural disaster, MPs <NUM> can be rerouted to different terminals <NUM> to circumnavigate the area affected by the natural disaster. Thus, having multiple terminals <NUM> that are geographically distributed can be turned into an advantage by allowing the rerouting of trailers <NUM> in real time. In some embodiments, new destination instructions can be communicated to mobile trailers <NUM> via a wireless communication interface such as cellular, radio, etc..

The freight <NUM> carried on each MP <NUM> is constrained by the trailer <NUM> that it must fit into. For example, most pup trailers are not allowed to convey more than <NUM>,<NUM> pounds. And, the width, length, and height are constraints that the pallets and parcels cannot exceed. Input data <NUM> generally contains the weight of each piece of freight <NUM>. However, in LTL shipping, the dimensions of freight <NUM> can vary greatly (e.g., long and narrow or cylindrical). Therefore, the cross-dock management system <NUM> may also employ a dimensioner array <NUM> which monitors the dimensions of each MP <NUM> to ensure that it does not exceed the interior size of the trailer <NUM>. Each space <NUM> on the dock <NUM> may be provided with its own dimensioner or one dimensioner may cover multiple spaces <NUM>. Preferably, a dimensioner is an imaging device capable of monitoring the boundaries of the MP <NUM> as well as the height of the decks <NUM> and freight <NUM> placed upon the MP <NUM>. The information from the dimensioner array <NUM> is collected and stored by dimensioner server <NUM>. And, as previously described, dimensioner server <NUM> may provide any video data to video server <NUM> for further analysis.

The information collected by dimensioner server <NUM> may be utilized by the real time instruction algorithms <NUM> if it is detected that a particular MP <NUM> has exceeded acceptable constraints to length, width, and height. If any excess is detected, the real time instruction algorithms <NUM> provide new instructions to instructions database <NUM>. Also, the dimensioner server <NUM> can be used to detect where irregular shaped freight <NUM> can be placed. For example, certain LTL shipments, such as ladders, could be placed on top of a MP <NUM> as long as the resulting load does not exceed a predetermined height and/or weight requirement.

The dimensioner array <NUM> can also be used to track the length, width, and height of the freight <NUM> placed on decks <NUM> to ensure it does not exceed a certain size limit. If it is determined that the size limit is exceeded, the real time instruction algorithms <NUM> can calculate new instructions to alleviate any problems.

As with any of the other described systems, such as the RFID server <NUM>, the dimensioner server <NUM> also generates exceptions if any irregularities on an MP <NUM> are discovered. For example, if the dimensioner server <NUM> detects that the width or length of an MP <NUM> is irregular, this may indicate that freight <NUM> is placed incorrectly or is in danger of falling off MP <NUM> or decks <NUM>.

Dimensioner array <NUM> may utilize any combination of known or future technologies capable of determining the outer dimensions of an object. For example, dimensioner array <NUM> may include vision systems such as HD video cameras or infrared laser scanners having low tolerances (e.g., <NUM>/<NUM>" or less). The dimensioner array <NUM> may scan an entire MP <NUM>, a single deck <NUM>, or individual pieces of freight <NUM>. The dimensioner array <NUM> can provide real time dimension data as freight <NUM> is conveyed. Each space <NUM> may be outfitted with its own dimensioner. Or, in other embodiments, a dimensioner may be outfitted on one or more drones which can cover multiple spaces <NUM>.

The weight of the freight <NUM> placed on deck <NUM> must also be tracked because each deck <NUM> is assigned a weight limit which is constrained by the amount of weight to be placed on posts <NUM>. The weight of decks <NUM> can be tracked using multiple means. For example, the conveyance vehicles or AGVs <NUM> used to move decks <NUM> may be outfitted with weight sensors (e.g., in the tines) that are able to detect the amount of weight being moved. The real time instruction algorithms <NUM> can then utilize this data to verify that an upper weight limit has not been exceeded for each deck <NUM> or to calculate new instructions.

Other sensors <NUM> may also be utilized to monitor MPs <NUM>. For example, each space <NUM> may be provided with a scale or other weight measuring device to ensure that the MP <NUM> does not exceed a certain weight limit. The weight sensors may also be pressure sensitive to determine if the load on each movable platform is distributed equally or logically (e.g., to place more weight on the end of MP <NUM> to prevent possible sag in the middle). The real time instruction algorithms <NUM> can use the data from other sensors <NUM> (e.g., temperature, humidity) to make any necessary corrections to instructions database <NUM>. It should be apparent to one of ordinary skill in the art that sensors may be added or deleted from cross-dock management system at any time simply by installing or removing the sensors and adapting the real time instruction algorithms <NUM> appropriately.

Cross-dock management system <NUM> also incorporates an AGV server <NUM> which is used to aid the navigation of each AGV <NUM> as well as monitor its real time location and status. For example, the AGV server <NUM> may utilize position information gathered by RFID server <NUM> to determine if each AGV <NUM> is in its correct location on dock <NUM>. The AGV server <NUM> can also be utilized to network all AGVs <NUM> so that each AGV <NUM> is aware of all AGV locations in real time. AGV server <NUM> may also be utilized to calculate the paths required for each AGV <NUM> to execute move instructions from instructions database <NUM> and to verify that each instruction is correctly performed.

AGV server <NUM> also incorporates remote control (RC) module <NUM> which allows any AGV <NUM> to be remotely controlled as has already been described. Thus, AGV server <NUM> provides an interface which allows AGVs <NUM> to be automated and or remotely controlled.

If multiple AGVs <NUM> are used on dock <NUM>, the real time instruction algorithms <NUM> can also take into account the cycling of AGVs <NUM> that must occur. That is, each AGV <NUM> will eventually need to be recharged, refueled, or be decommissioned for maintenance. In those instances, the real time instruction algorithms <NUM> would reallocate moves to new AGVs <NUM> or temporarily assign workers if no additional AGVs <NUM> are available. In this manner, the workflow on the dock <NUM> is not interrupted.

The AGVs <NUM> may each utilize different guidance systems or each AGV <NUM> may utilize one or more different guidance methods in isolation or in combination. For example, the AGVs <NUM> tasked with moving MPs <NUM> may only need to use a much simpler guidance method such as a combination of guide tape and natural feature navigation, ceiling tag (or other visual marker) navigation, infrared sensors, marker grid navigation. Infrared navigation offers the advantage that it is not interrupted by interference from visible lights. Passive infrared tags placed throughout the dock <NUM> may indicate a specific location on dock <NUM>. AGV navigation can be supplemented by other navigation techniques such as odometry, active RFID, passive RFID, and/or SLAM (simultaneous location and mapping).

AGVs <NUM> tasked with moving decks <NUM> or individual pieces of freight <NUM> would require the use of one or more sophisticated guidance methods such as laser target navigation, inertial navigation, vision guidance, and/or geoguidance. A properly setup AGV guidance system would allow for multiple improvements within cross-dock management system <NUM>. First, a fully (or mostly) automated AGV system would have much less downtime than one staffed solely by workers <NUM> because no rest or stops would occur. Further, because the navigation is very precise, the distance between spaces <NUM> could possibly be reduced, allowing even more spaces <NUM> to be placed on dock <NUM>.

The AGVs <NUM> may also be modular as has already been described. For example, each AGV <NUM> may be outfitted with a video camera to supplement the video gathered by video server <NUM>. The AGVs <NUM> may also be able to receive modular attachments to perform other functions such as cleaning (e.g., vacuum or broom attachment) or placing securement (e.g., shoring beams).

For illustration purposes, the steps utilized to unload and load MPs <NUM> on a trailer <NUM> will be described in detail using the flowchart of <FIG> referencing the docks <NUM> shown in <FIG> or <FIG> and the various components of cross-dock management system <NUM> shown in <FIG>. First, an inbound trailer <NUM> containing a MP <NUM> arrives at the terminal <NUM> in step <NUM>. The trailer <NUM> is then directed to a particular door in step <NUM> using instructions retrieved from instructions database <NUM>. The MP <NUM> is then unloaded from the trailer in step <NUM> and scanned by a worker using tablet <NUM>. Also, at this point, the RFID array <NUM> will have scanned any RFID tags contained on the MP <NUM> since it is now located on dock <NUM>. If the RFID array <NUM> identifies an RFID tag or tags that should not be present (e.g., not in the manifest data), an exception is generated so that the correct destination of the freight <NUM> can be determined. This allows misplaced freight <NUM> to be identified much earlier during transmission of the cargo.

Using the instructions provided by instructions database <NUM>, the MP <NUM> is then conveyed into its optimized space <NUM> on dock <NUM> in step <NUM>. The worker <NUM> verifies that the MP <NUM> has been properly moved by scanning an identifier associated with the optimized space <NUM> along with any of the identifiers provided on MP <NUM> in step <NUM>. Alternatively, or in addition, the RFID array <NUM> or other sensors <NUM> may also be utilized to verify that the MP <NUM> is in the optimized space <NUM>.

Any securement, such as shoring beams or cargo straps, are then removed from MP <NUM> in step <NUM>. Step <NUM> can be performed manually by workers <NUM> or by an AGV <NUM> as has already been described. After it is verified that all securement has been removed in step <NUM>, the unloading/loading of MP <NUM> commences.

At this point, workers <NUM> are provided with the worker instructions and AGVs <NUM> are provided with AGV instructions from instructions database <NUM> in step <NUM>. For each MP <NUM>, the workers <NUM> and AGVs <NUM> carry out all assigned moves for the MP <NUM> in step <NUM>. The specifics of step <NUM> as to how specific instructions, such as deck or freight movements, are carried out by AGVs <NUM> will be described with reference to <FIG>, <FIG>, and <FIG> later.

The instructions carried out by the workers <NUM> and AGVs <NUM> in step <NUM> can be classified as either a freight move (moving a single parcel or pallet) or a deck instruction (moving decks <NUM>). Deck instructions are advantageous because what previously would have taken several freight moves can now be accomplished in a single deck move. Also, because the freight on the deck <NUM> is not touched, there is far less likelihood that the freight on deck <NUM> will become damaged during a deck move. With decks <NUM>, it is possible that freight placed thereon is only handled individually at the origin and destination docks <NUM>.

After all instructions for MP <NUM> have been carried out, securement must be placed in step <NUM> (either manually or using an AGV). After the cross-dock management system <NUM> is notified that the securement has been placed in <NUM>, an alert is generated to notify the supervisor (or similar personnel) that the MP <NUM> is ready to be inspected. In step <NUM>, a supervisor verifies that MP <NUM> meets all specifications and that securement has been placed properly. For example, the supervisor may check to see if any freight <NUM> has been damaged.

Next, using instructions retrieved from instructions database <NUM>, secured MP <NUM> is conveyed to a particular door to a waiting, empty trailer <NUM> in step <NUM>. It should be noted that since a MP <NUM> can be quickly unloaded and unloaded as has been described, the empty trailer <NUM> does not have to wait at dock <NUM> and instead can wait in a yard. Then, when the MP <NUM> is ready to be loaded (e.g., after steps <NUM> or <NUM>), the correct trailer <NUM> in the yard can be notified and assigned a door to drive to for loading. Thus, it should be apparent that this provides a significant advantage over traditional LTL methods at which trailers generally have to stay at the door for long periods while they are unloaded or loaded. The cross-dock management system <NUM> of the present invention only requires the presence of trailers <NUM> at doors if a MP <NUM> is being unloaded or loaded.

Before MP <NUM> is loaded into trailer <NUM>, a worker scans an identifier associated with MP <NUM> along with an identifier associated with the trailer <NUM> or door in step <NUM>. This process can also be automated using RFID array <NUM>. Step <NUM> associates the outbound MP <NUM> with a particular trailer and creates new manifest data that can be provided to the next terminal <NUM>.

The MP <NUM> is then loaded onto the trailer <NUM> in step <NUM> and the trailer <NUM> departs in step <NUM>. Steps <NUM>-<NUM> are repeated for each inbound MP <NUM> on dock <NUM>.

The steps utilized for moving decks <NUM> with a pair of AGVs <NUM> in a deck instruction will be described with reference to <FIG>. It is first determined in step <NUM> if all freight on a particular deck <NUM> is destined for the same outbound MP <NUM> or storage area (to be described later). If the determination is positive, the beginning of the move of deck <NUM> is started in step <NUM>. The AGVs <NUM> utilized to move deck <NUM> in this described method are pairs of AGVs <NUM> which engage the sides of decks <NUM> in unison as will now be described. First, the AGV team is initiated and moves into position on the sides of deck <NUM> which is to be moved in step <NUM> in accordance with the provided deck instruction. Each AGV <NUM> then positions itself to the level of the deck <NUM> to be moved in step <NUM>. As has been explained, the height of each deck <NUM> on each MP <NUM> is known (e.g., from the manifest data or other calculated instructions) and this information is provided in the deck instruction. Each AGV <NUM> then engages deck <NUM> on each side in step <NUM>. If deck <NUM> does not include slots <NUM>, other gripping means may be utilized for the AGV <NUM> to attach to deck <NUM> (e.g., deck <NUM> can be lifted from beneath).

Each AGV then lifts deck <NUM> above posts <NUM> in step <NUM>. Deck <NUM> is longitudinally conveyed to the end of MP <NUM> in step <NUM>. At this point, deck <NUM> is lowered to travel height by the AGVs <NUM> (e.g., to prevent toppling) in step <NUM>. The supplied deck instruction includes a destination for the deck <NUM>. As previously mentioned, the deck <NUM> may be conveyed to (a) another MP <NUM> or (b) a storage area as shown in decision step <NUM>. If the destination is another MP <NUM>, deck <NUM> is conveyed to the appropriate end of a destination MP <NUM> in step <NUM>. The AGVs <NUM> then raise deck <NUM> to the appropriate height for placement in step <NUM> and then lower deck <NUM> onto posts <NUM> in step <NUM>. Deck <NUM> is then released in step <NUM> at which point the AGVs <NUM> are available for the next move. Alternatively, if the destination for the deck <NUM> is a storage area after step <NUM>, the AGVs <NUM> convey the deck <NUM> to the storage area in step <NUM>.

The steps utilized for moving decks <NUM> with a single AGV <NUM> having a pair of forklift tines will now be described with reference to <FIG>. It is first determined in step <NUM> if all freight on a particular deck <NUM> is destined for the same outbound MP <NUM> or storage area. If the determination is positive, the beginning of the move of deck <NUM> is started in step <NUM>. First, the AGV <NUM> is initiated and moves into position at deck <NUM> which is to be moved in step <NUM> in accordance with the provided deck instruction. The AGV <NUM> then positions itself to the level of the deck <NUM> to be moved in step <NUM> and raises its tines in step <NUM>. As has been explained, the height of each deck <NUM> on each MP <NUM> is known (e.g., from the manifest data or other calculated instructions) and this information is provided in the deck instruction. The AGV <NUM> then slots <NUM> in deck <NUM> and lifts deck <NUM> in step <NUM>.

AGV <NUM> reverses direction until deck <NUM> clears posts <NUM> in step <NUM>. At this point, deck <NUM> is lowered to travel height by the AGV <NUM> (e.g., to prevent toppling) in step <NUM>. The supplied deck instruction includes a destination for the deck <NUM>. As previously mentioned, the deck <NUM> may be conveyed to (a) another MP <NUM> or (b) a storage area as shown in decision step <NUM>. If the destination is another MP <NUM>, deck <NUM> is conveyed to the appropriate location of a destination MP <NUM> in step <NUM>. The AGV <NUM> then raises deck <NUM> to the appropriate height for placement in step <NUM> and then lower deck <NUM> onto posts <NUM> in step <NUM>. Deck <NUM> is then released in step <NUM> at which point the AGV <NUM> is available for the next move. Alternatively, if the destination for the deck <NUM> is a storage area after step <NUM>, the AGV <NUM> conveys the deck <NUM> to the storage area in step <NUM>.

Referring now to <FIG>, described is a process that occurs when the initial setup optimization <NUM> determines that a plurality of decks <NUM> can be more optimally rearranged to direct freight <NUM> to its proper destination. For example, the initial setup optimization <NUM> may determine, based on the manifest data, that the freight on one or more decks <NUM> can be more optimally rearranged to increase the capacity utilization of trailers <NUM>. This process may only occur if the initial setup optimization <NUM> determines that a predetermined number of decks <NUM> can be rearranged, thus making rearranging freight <NUM> worthwhile.

First, workers <NUM> or AGVs <NUM> are utilized to move the decks <NUM> to be rearranged to a freight area in step <NUM>. The rearranging is preferably done in a separate area of the dock <NUM> away from spaces <NUM> because of the more cautious moves required when moving freight <NUM>. After all the decks <NUM> have been placed in the freight area, the freight <NUM> on decks <NUM> is rearranged according to instructions calculated by initial setup optimization <NUM> in step <NUM>. Next, in order to make use of any leftover space on decks <NUM>, freight <NUM> from the storage area may be moved to empty spaces on decks <NUM> in step <NUM>. The decks <NUM> can then be placed on MPs <NUM> in step <NUM>.

It is contemplated that one or more different types of AGVs <NUM> may be utilized in combination with the present invention. For example, a first type of AGV <NUM> may be utilized to move MPs <NUM> in/out of trailers <NUM> and onto dock <NUM>. These AGVs <NUM> may require simpler construction than others because they only need to hook onto MPs <NUM> and move them around dock <NUM>.

A second type of AGV <NUM> may be utilized to execute deck instructions or, in certain environments, single freight instructions as described with reference to <FIG>. With regards to moving decks <NUM>, this second type of AGV <NUM> could operate alone or in pairs to move decks <NUM> about dock <NUM> as has been described in <FIG> and <FIG>. If in pairs, a first AGV <NUM> may act as a master AGV and be in communication with cross-dock management system <NUM> to receive instructions and carry out orders. The second AGV <NUM> would be controlled by the master AGV and function as a slave AGV. The slave AGV would be less costly as it would not require all of the features and communication equipment of the master AGV.

A third type of AGV <NUM> could be utilized to execute single freight instructions, primarily (moving of single freight <NUM> from a first MP <NUM> to a second MP <NUM>). Since these AGVs <NUM> would only be responsible for moving smaller freight <NUM> (less than a full deck <NUM>), they would be less expensive to produce and maintain. They would also require a much smaller footprint than the first or second type of AGV <NUM> described above. It should be obvious that the less space that is taken up by AGVs <NUM> on the dock <NUM>, there is less potential for collisions and other mishaps. As an example, these AGVs <NUM> may simply have a weight bearing platform with automated rollers on top. The AGVs <NUM> could use a centralized system of rollers to pick up and drop off freight <NUM>. Such AGVs <NUM> may be useful for long haul movements such as moving freight from dock <NUM> to a storage area and vice versa.

However, it is also possible for a single type of AGV <NUM> to execute all of the moves required by the present invention. Such an AGV may potentially be more costly, but maintenance and other costs could be kept to a minimum because different systems/sets of AGVs <NUM> would not have to be maintained across multiple docks <NUM>.

Each deck instruction contains the location of the source deck <NUM> and a location of the destination MP <NUM>. Further, the deck instruction also includes the height at which the source deck is located. As already stated, the heights at which decks <NUM> are placed on posts <NUM> are preferably standardized. Therefore, each deck height can be assigned a unique identifier (<NUM>-x), similar to the section identifiers. Thus, the sections A-F and the differing deck placement heights can all be standardized by using a combination of a section identifier and a height identifier on each MP <NUM>. An example deck instruction would be as follows: ORIGIN: [MP identifier, section identifier, height identifier]-DESTINATION[MP identifier, section identifier, height identifier]. Such a deck instruction includes all necessary information to move a deck <NUM> from an origin to a destination.

Freight instructions may also be structured in a similar manner. However, more information may be needed in a freight instruction for both the origin and the destination. Similar to deck instructions, freight instructions may utilize a similar structure. A freight instruction may additionally include a quadrant location (using identifiers <NUM> and/or tags <NUM>) location for further specificity. That is, the more information that can be provided to the cross-dock management system <NUM> about the particulars of the dock <NUM> and the particulars of moves, the more that can be automated.

As has already been described, the initial setup optimization <NUM> is able to divide instructions into worker instructions and AGV instructions using a variety of criteria. For example, because deck/MP instructions are simpler and MPs <NUM> and decks <NUM> are fairly large and standardized, only those moves may be automated while the other moves may be carried out by workers <NUM>. Any combination of automation/manual moves are compatible with the present invention because the instructions are the same regardless. The only difference is the receiver of the instruction (worker <NUM> or AGV <NUM>) and these instructions be rerouted on the fly by the real time instruction algorithms <NUM>.

As another example, AGV server <NUM> may keep track of how many moves each AGV <NUM> has executed. If it is determined that a particular AGV <NUM> has been overburdened, this information may be supplied to real time instruction algorithms <NUM> so that the moves among AGVs <NUM> are distributed more evenly. This would allow the work load assigned to each AGV <NUM> to be balanced which would lead to less breakdowns and maintenance.

In some embodiment, individual pieces of freight may also be assigned unique identifiers to note special properties or allow them to be moved using an AGV. For example, some freight may be marked as delicate. Delicate freight is preferably manually loaded onto a deck <NUM> or a MP <NUM>. For example, if freight is marked as delicate and there is enough delicate freight to fill a deck <NUM>, the deck <NUM> may be loaded manually first and then an AGV <NUM> could be used to move the loaded deck <NUM> into a final position. It is a particular strength of the present invention that it can handle interruptions and automatically reroute the workflow around dock <NUM> to handle those interruptions (such as the needed loading of a manual deck <NUM>). Also, since the system of the present invention knows the inbound manifest data, which would also include such freight indicators, the other instructions could be optimized to minimize the impact to workflow while the delicate freight (or other awkward freight) is being loaded manually.

The storage facility in which decks <NUM> are placed may take many forms. If there is a requirement for only occasional storage of decks <NUM> (e.g., delayed schedule or delivery, etc.), the storage area may simply be a portion of dock <NUM> having assigned spaces for decks <NUM>. The cross-dock management system <NUM> would simply log the location of each placed deck <NUM>, similar to the MPs <NUM>, so that it could be recalled when needed. However, if a great number of decks <NUM> need to be stored, a rack system could be utilized in which a number of racks (e.g., composed of four posts <NUM>) could be arranged on dock <NUM> or at a different location. Each rack would be assigned an identifier and the height that each deck is stored at would be noted by cross-dock management system for later recall of the deck. A rack system maximizes floor space. In particular, the racks could be placed against the walls of the dock <NUM> to minimize the floor space taken up.

Still, in another embodiment, the storage facility may be an entirely separate and automated facility if multiple decks <NUM> are to be stored long term. Such a facility would be useful, for example, for individuals traveling abroad that need to store items for long periods of time. Such individuals could be rented storage space in various sizes (an entire movable platform, a single deck, or combinations thereof) and those could be stored/retrieved at any time.

<FIG> depicts a flowchart showing the steps utilized by initial setup optimization <NUM> to calculate instructions from input data <NUM>. First, in step <NUM>, the input data <NUM> is received and stored in local warehouse database <NUM>. Based on the received manifests in input data <NUM>, all outbound load points are identified by initial setup optimization <NUM> in step <NUM>. Using this information, the number of MPs <NUM> for each load point can be determined in step <NUM>. For example, an inbound MP <NUM> may have freight <NUM> or decks <NUM> which need to be transferred to three different destinations and would require at least two additional MPs <NUM> (i.e., because the inbound MP <NUM> is reused as an outbound MP <NUM> once it has been unloaded/reloaded).

Next, for each inbound MP <NUM>, the initial setup optimization determines which freight <NUM> or decks <NUM> need to be handled in step <NUM>. For example, if the majority of pieces on a MP <NUM> are intended for the same terminal <NUM>, only a few select pieces need to be removed/loaded onto the MP <NUM> until it is ready to be loaded onto a waiting trailer <NUM>. This can significantly speed up the loading/loading process over the conventional LIFO process. Similarly, if all of the freight <NUM> located on a deck <NUM> is intended for the same destination, only a single deck instruction needs to be calculated. If additional MPs <NUM> are needed, the initial setup optimization <NUM> adds additional MP movements to the instructions in step <NUM>. Also, has already been described, additional MPs <NUM> can be placed overnight by AGVs <NUM> before any trailers <NUM> arrive.

If decks <NUM> and freight <NUM> are capable of being moved on dock <NUM>, the initial setup optimization <NUM> will use a bin stacking algorithm to determine an optimal height at which each deck and/or freight <NUM> is to be placed during a deck or freight instruction. The initial setup optimization <NUM> calculates the deck instruction using the weight as well as the known dimensions (<NUM> x w x h) of each deck <NUM>. As already noted, the real time instruction algorithms <NUM> can correct any wrong instructions which have been calculated during the initial setup optimization.

Based upon a plurality of criteria (weight, number of parcels, number of inbound/outbound MPs <NUM>, number of pieces to be handled), the initial setup optimization <NUM> determines an optimized space <NUM> for each MP <NUM> on dock <NUM> in step <NUM>. The initial setup optimization <NUM> also determines the number of workers <NUM> and/or AGVs <NUM> required to complete all necessary moves in step <NUM>. This step avoids having too many or too few workers <NUM> or AGVs <NUM> located on dock <NUM>.

Based upon the number of assigned workers <NUM> and AGVs <NUM> (step <NUM>) and the number of pieces to be handled (step <NUM>), the initial setup optimization <NUM> determines all piece level moves for the workers <NUM> and AGVs <NUM> (freight instructions and deck instructions) in step <NUM>. The instructions are then stored in instructions database <NUM> in step <NUM>. Step <NUM>-<NUM> are repeated daily for each set of input data <NUM> that is received by cross-dock management system <NUM>.

In LTL shipping, shippers may desire to ship anywhere from a single piece of freight to an entire trailer, or anything in between. Therefore, for each shipper and pickup, it may be important to note and classify the shipments being picked up or dropped off at each facility. Further, this information will later be compiled into manifest data provided to each terminal <NUM> (and later used to calculate instructions and to route freight). Therefore, the more that is known about freight at the origin, the better the various cross-dock systems can manage the freight through the hub and spoke terminals <NUM>. The following classifications of freight provided by a shipper at an original are possible:.

By classifying the pickups into these different categories, the origin dock <NUM> can better ascertain what equipment will be needed to conduct the first leg of the shipment (i.e., number of movable platforms needed, number of trailers needed). Further, classifying the information at pickup allows the freight <NUM> to be tagged at the earliest possible location (i.e., at pickup) and greatly reduces the possibility that freight <NUM> will be mislabeled or end up at the wrong terminal <NUM>. For example, if it is noted early on that a MP <NUM> has freight intended for a single destination, the cross-dock management system <NUM> can route this MP <NUM> without having to calculate any deck instructions or freight instructions, thus reducing the complexity of the instruction calculations. Similarly, for decks <NUM> having freight for a single destination, only deck instructions have to be calculated.

<FIG> depicts terminal <NUM> of <FIG> adapted for use with MPs <NUM>. In some instances, it may not be feasible for an LTL shipper to modify the layout of dock <NUM>. However, dock <NUM> can be made to be compatible with MPs <NUM> using the dock configuration shown in <FIG>. As shown, MPs <NUM> are placed at every other door <NUM> to allow access to three sides of MP <NUM> both on the inbound doors <NUM> and outbound doors <NUM>. This creates a central aisle <NUM> which allows for easy movement of MPs <NUM> and freight <NUM>. It should be apparent to one of ordinary skill in the art that initial setup optimization <NUM> and real time instruction algorithms <NUM> can be adapted to work with the dock configuration shown in <FIG>.

<FIG> depicts a shared dock <NUM> which is share between independent carriers located in the same geographical region that have a partnership for the purposes of sharing data. In such cases, predictive analytics can optimize loads by combining partner carrier freight (e.g., shipment parcels) onto the same MP <NUM>, further reducing truck schedules and cost. As shown, a first side <NUM> of dock <NUM> is occupied by a first carrier and a second side <NUM> of dock <NUM> is occupied by a second carrier. First side <NUM> and second side <NUM> may be split equally or according to the terms of a partnership agreement. Information about MPs <NUM> and RFID tags can be made available from the first side <NUM> to the second side <NUM>, and vice versa. However, each side <NUM> and <NUM> is preferably controlled by its own cross-dock management system <NUM> to provide data confidentiality. The two cross-dock management systems <NUM> may be linked in order to share limited data. As an example, the cross-dock management system <NUM> associated with first side <NUM> may determine that it is more economically feasible to have the second side <NUM> deliver certain parcels. The second side <NUM> may agree or disagree to each request from first side <NUM>.

<FIG> depicts a flowchart showing the collaboration between two cross-dock management systems <NUM> which share dock <NUM>. The cross-dock management system <NUM> associated with first side <NUM> is cross-dock management system A and the cross-dock management system <NUM> associated with first side <NUM> is cross-dock management system B. Cross-dock management systems A and B each feed collaboration data into collaboration heuristic model <NUM>. Collaboration data may include information such as the number of available spaces on MPs <NUM>, the destinations of all MPs <NUM>, manifest data about any overflow freight <NUM> (i.e., a parcel which would require an extra shipment or does not fit within available MPs <NUM>), etc. The collaboration heuristic model <NUM> compares the collaboration data from cross-dock management systems A and B and determines options <NUM> for carrier A and options <NUM> for carrier B. Carrier A and Carrier B can agree/disagree to each option or cross-dock management systems A and B may be programmed to automatically accept/deny certain options in step <NUM>. Any options that agreed upon will be updated in the instructions database <NUM> as computed by real time instruction algorithms <NUM> in step <NUM>.

Although various embodiments have been described with reference to a particular arrangement of parts, features, and the like, these are not intended to exhaust all possible arrangements or features, and indeed many other embodiments, modifications, and variations will be ascertainable to those of skill in the art. Thus, it is to be understood that the invention may therefore be practiced otherwise than as specifically described above.

Claim 1:
A cross-dock management system (<NUM>) comprising:
a cross-dock (<NUM>) having a plurality of doors at opposing ends of the cross-dock for receiving inbound trailers and for loading outbound trailers;
a plurality of separated spaces (<NUM>) arranged in a grid pattern on the cross-dock, wherein the grid pattern comprises at least three rows and at least three columns;
a plurality of movable platforms (<NUM>) arranged on the cross-dock in the separated spaces, wherein an area of each movable platform is substantially the same as an area of the separated spaces;
a plurality of conveyance vehicles (<NUM>), wherein a first subset of the plurality of conveyance vehicles are manually operated conveyance vehicles, and wherein a second subset of the plurality of conveyance vehicles are automated guided vehicles, AGVs;
a local database (<NUM>) for storing received manifest data; and
an initial setup optimization server (<NUM>) for determining a plurality of ordered move instructions for moving the inbound movable platforms, the inbound modular decks, and the inbound freight based upon the manifest data,
characterised in that:
the manifest data includes information classifying inbound movable platforms, inbound modular decks, and inbound freight as AGV-compatible or AGV-incompatible;
a first subset of the ordered move instructions are assigned to and performed by the AGVs, and a second subset of the ordered move instructions are assigned to and performed by the manually operated conveyance vehicles,
wherein:
the plurality of separated spaces are angled at approximately <NUM>-<NUM>° with respect to the plurality of doors;
the plurality of movable platforms each comprise:
a plurality of vertical posts (<NUM>) each having a respective readable tag (<NUM>) assigned thereto for identifying its specific post;
a plurality of engagement members on each vertical post configured to receive modular decks (<NUM>) placed on the plurality of engagement members at varying heights;
a plurality of section identifiers each configured to identify a specific location and height on the movable platform; and
each of the plurality of ordered move instructions determined by the initial setup optimization server (<NUM>) comprises destination information that includes a section identifier, a post location, and a side that specifies where freight (<NUM>) is to be placed on one of the plurality of movable platforms.