SYSTEMS AND METHODS FOR OPTIMIZING LOAD OPERATIONS OF A HUB

Description

PRIORITY

This application claims the benefit, under 35 U.S.C. § 119(e), of U.S. Provisional Patent Application No. 63/677,311, filed Jul. 30, 2024, the entirety of which is herein incorporated by reference for all purposes.

TECHNICAL FIELD

The present disclosure relates generally to intermodal hub facilities, and more particularly to systems and devices for optimizing load operations of an intermodal hub facility.

BACKGROUND

Intermodal hub facilities are integral to the logistics and transportation sector, acting as central points for the transfer of goods between various transportation modes, including trains, trucks, and ships. The seamless operation of these hubs is a cornerstone for the uninterrupted flow of goods throughout the supply chain, which is increasingly demanding due to the growth in global trade and the push for faster delivery times.

A core activity within these facilities is the management of inbound and outbound train operations. Trains arrive with containers and trailers-key units in intermodal transport-delivering goods to the hub (inbound) or taking goods away towards their final destinations (outbound). The efficiency of handling these units directly impacts the performance of the hub and the broader supply chain. For example, determining which containers and trailers to load on outbound railcars and how/when to load them is critical to the performance of the hub. Typically, a “load plan” is developed and used to load containers and trailers (i.e., “units”) onto outbound railcars. The load plan is an assignment between units and railcars and typically requires a manual and time-consuming process to generate.

SUMMARY

The present disclosure achieves technical advantages as systems, methods, and computer-readable storage media for optimizing load operations of an intermodal hub facility. The functionality for optimizing load operations of a hub is based on automatically generating load plans based on priority (e.g., service levels) and driving distances from unit parking spots to trackside locations.

In embodiments, the present disclosure provides for a system integrated into a practical application with meaningful limitations as a load operations optimization system with functionality for optimizing load operations of a hub. In embodiments, the load operations optimization system may be configured to access train data for a hub, access user preferences, and determine driving distances for units of an outbound train. The load operations optimization system may be further configured to determine a track loading order, determine units to load, and the automatically generate a load plan that minimizes hostler travel distances while meeting all rules and requirements (priority, service levels, etc.).

A technical improvement of the features provided herein includes automatically generating load plans that minimize hostler travel distances while meeting all rules and requirements. This generation process contributes to the overall efficiency of the hub operations. In addition, the system of embodiments can generate control signals for automatically managing physical assets based on the generated load plans, allowing for automated or guided positioning of equipment.

Collectively, these technical improvements provided by the load operation optimization functionality of the present disclosure contribute to a more efficient, reliable, and adaptable hub facility, capable of handling the complexities of modern freight transportation.

Thus, it will be appreciated that the technological solutions provided herein, and missing from conventional systems, are more than a mere application of a manual process to a computerized environment, but rather include functionality to implement a technical process to replace or supplement current manual solutions or non-existing solutions for optimizing resources in hubs. In doing so, the present disclosure goes well beyond a mere application the manual process to a computer. Accordingly, the disclosure and/or claims herein necessarily provide a technological solution that overcomes a technological problem.

Furthermore, the functionality for optimizing load operations in a hub facility provided by the present disclosure represents a specific and particular implementation that results in an improvement in the utilization of a computing system for resource optimization. Thus, rather than a mere improvement that comes about from using a computing system, the present disclosure, in enabling a system to leverage and optimize load operations to optimize the unit throughput of the hub, represents features that result in a computing system device that can be used more efficiently and is improved over current systems that do not implement the functionality described herein. As such, the present disclosure and/or claims are directed to patent eligible subject matter.

In embodiments, the present disclosure includes techniques for training models (e.g., machine-learning models, artificial intelligence models, algorithmic constructs, etc.) for performing or executing a designated task or a series of tasks (e.g., one or more features for optimizing load operations in a hub facility in accordance with embodiments of the present disclosure). The disclosed techniques provide a systematic approach for the training of such models to enhance performance, accuracy, and efficiency in their respective applications. In embodiments, the techniques for training the models may include collecting a set of data from a database, conditioning the set of data to generate a set of conditioned data, and/or generating a set of training data including the collected set of data and/or the conditioned set of data. In embodiments, that model may undergo a training phase wherein the model may be exposed to the set of training data, such as through an iterative processes of learning in which the model adjusts and optimizes its parameters and algorithms to improve its performance on the designated task or series of tasks. This training phase may configure the model to develop the capability to perform its intended function with a high degree of accuracy and efficiency. In embodiments, the conditioning of the set of data may include modification, transformation, and/or the application of targeted algorithms to prepare the data for training. The conditioning step may be configured to ensure that the set of data is in an optimal state for training the model, resulting in an enhancement of the effectiveness of the model's learning process. These features and techniques not only qualify as patent-eligible features but also introduce substantial improvements to the field of computational modeling. These features are not merely theoretical but represent an integration of a concepts into a practical applications that significantly enhance the functionality, reliability, and efficiency of the models developed through these processes.

In embodiments, the present disclosure includes techniques for generating a notification of an event (e.g., a parking spot assignment, a hostler operation, a paired hostler operation, a load plan, an optimized track-train assignment sequence, etc.) includes generating an alert that includes information specifying the location of a source of data associated with the event, formatting the alert into data structured according to an information format; and transmitting the formatted alert over a network to a device associated with a receiver based upon a destination address and a transmission schedule. In embodiments, receiving the alert enables a connection from the device associated with the receiver to the data source over the network when the device is connected to the source to retrieve the data associated with the event and causes a viewer application (e.g., a graphical user interface (GUI)) to be activated to display the data associated with the event. These features represent patent eligible features, as these features amount to significantly more than an abstract idea. These features, when considered as an ordered combination, amount to significantly more than simply organizing and comparing data. The features address the Internet-centric challenge of alerting a receiver with time sensitive information. This is addressed by transmitting the alert over a network to activate the viewer application, which enables the connection of the device of the receiver to the source over the network to retrieve the data associated with the event. These are meaningful limitations that add more than generally linking the use of an abstract idea (e.g., the general concept of organizing and comparing data) to the Internet, because they solve an Internet-centric problem with a solution that is necessarily rooted in computer technology. These features, when taken as an ordered combination, provide unconventional steps that confine the abstract idea to a particular useful application. Therefore, these features represent patent eligible subject matter.

In various embodiments, the system comprises one or more processors interconnected with a memory module, capable of executing machine-readable instructions. These instructions include, but are not limited to, the steps outlined in any flow diagram, system diagram, block diagram, and/or process diagram disclosed herein, as well as steps corresponding to any functionality detailed herein. In embodiments, the execution of these machine-readable instructions may involve initiating multiple concurrent computer processes. Each process of the concurrent computer process may be configured to handle or process a designated subset or portion of the of the machine-readable instructions. This division of tasks enables parallel processing, multi-processing, and/or multi-threading, enabling multiple operations to be conducted or executed concurrently rather than sequentially. This functionality for spawning a plurality of concurrent processes to manage separate portions of the machine-readable instructions markedly increases the overall speed of execution of the machine-readable instructions. By leveraging parallel or concurrent processing, the time required to complete a set or subset of program steps is substantially reduced (e.g., when compared to execution without concurrent or parallel processing). This efficiency gain not only accelerates the processing speed but also optimizes the use of processor resources, leading to an improved performance of the computing system. This enhancement in computational efficiency constitutes a significant technological improvement, as it enhances the functional capabilities of the processors and the system as a whole, representing a practical and tangible technological advancement. The result of this concurrent processing functionality results in an improvement in the functioning of the one or more processor and/or the computing system, and thus, represents a practical application.

In embodiments, one or more operations and/or functionality of components described herein can be distributed across a plurality of computing systems (e.g., personal computers (PCs), user devices, servers, processors, etc.), such as by implementing the operations over a plurality of computing systems. This distribution can be configured to facilitate the optimal load balancing of traffic (e.g., requests, responses, notifications, etc.), which can encompass a wide spectrum of network traffic or data transactions. By leveraging a distributed operational framework, a system implemented in accordance with embodiments of the present disclosure can effectively manage and mitigate potential bottlenecks, ensuring equitable processing distribution and preventing any single device from shouldering an excessive burden. This load balancing approach significantly enhances the overall responsiveness and efficiency of the network, markedly reducing the risk of system overload and ensuring continuous operational uptime. The technical advantages of this distributed load balancing can extend beyond mere efficiency improvements. It introduces a higher degree of fault tolerance within the network, where the failure of a single component does not precipitate a systemic collapse, markedly enhancing system reliability. Additionally, this distributed configuration promotes a dynamic scalability feature, enabling the system to adapt to varying levels of demand without necessitating substantial infrastructural modifications. The integration of advanced algorithmic strategies for traffic distribution and resource allocation can further refine the load balancing process, ensuring that computational resources are utilized with optimal efficiency and that data flow is maintained at an optimal pace, regardless of the volume or complexity of the requests being processed. Moreover, the practical application of these disclosed features represents a significant technical improvement over traditional centralized systems. Through the integration of the disclosed technology into existing networks, entities can achieve a superior level of service quality, with minimized latency, increased throughput, and enhanced data integrity. The distributed approach of embodiments can not only bolster the operational capacity of computing networks but can also offer a robust framework for the development of future technologies, underscoring its value as a foundational advancement in the field of network computing.

To aid in the load balancing, the computing system of embodiments of the present disclosure can spawn multiple processes and threads to process data traffic concurrently. The speed and efficiency of the computing system can be greatly improved by instantiating more than one process or thread to implement the claimed functionality. However, one skilled in the art of programming will appreciate that use of a single process or thread can also be utilized and is within the scope of the present disclosure.

It is an object of the disclosure to provide a method of optimizing load operations in a hub facility. It is a further object of the disclosure to provide a system for optimizing load operations in a hub facility, and a computer-based tool for optimizing load operations in a hub facility. These and other objects are provided by the present disclosure, including at least the following embodiments.

In one particular embodiment, a method of optimizing load operations in a hub facility is provided. The method includes accessing train data for a hub and accessing one or more user preferences of a plurality of user preferences. The method further includes determining, based on the train data, a driving distance for each of a plurality of candidate units to be loaded on an outbound train. The method further includes determining, based on the determined driving distances for the candidate units to be loaded on the outbound train, a track order. The method further includes determining, based on the determined track order, a plurality of units from the plurality of candidate units to load on the outbound train. The method further includes generating a load plan using the determined plurality of units to load on the outbound train.

In another embodiment, a system for optimizing load operations in a hub facility is provided. The system includes one or more memory units configured to store train data for a hub and a plurality of user preferences. The system further includes one or more computer processors communicatively coupled to the one or more memory units and configured to perform operations comprising accessing the train data for a hub and accessing one or more user preferences of the plurality of user preferences. The operations further include determining, based on the train data, a driving distance for each of a plurality of candidate units to be loaded on an outbound train. The operations further include determining, based on the determined driving distances for the candidate units to be loaded on the outbound train, a track order. The operations further include determining, based on the determined track order, a plurality of units from the plurality of candidate units to load on the outbound train. The operations further include generating a load plan using the determined plurality of units to load on the outbound train.

In yet another embodiment, one or more computer-readable non-transitory storage media embodying instructions are provided. The instructions, when executed by a processor, cause the processor to perform operations comprising accessing train data for a hub and accessing one or more user preferences of a plurality of user preferences. The operations further include determining, based on the train data, a driving distance for each of a plurality of candidate units to be loaded on an outbound train. The operations further include determining, based on the determined driving distances for the candidate units to be loaded on the outbound train, a track order. The operations further include determining, based on the determined track order, a plurality of units from the plurality of candidate units to load on the outbound train. The operations further include generating a load plan using the determined plurality of units to load on the outbound train.

The foregoing has outlined rather broadly the features and technical advantages of the present disclosure in order that the detailed description of the disclosure that follows may be better understood. Additional features and advantages of the disclosure will be described hereinafter which form the subject of the claims of the disclosure. It should be appreciated by those skilled in the art that the conception and specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present disclosure. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the disclosure as set forth in the appended claims. The novel features which are believed to be characteristic of the disclosure, both as to its organization and method of operation, together with further objects and advantages will be better understood from the following description when considered in connection with the accompanying figures. It is to be expressly understood, however, that each of the figures is provided for the purpose of illustration and description only and is not intended as a definition of the limits of the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present disclosure, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

FIG. 1 is a block diagram of an exemplary system configured with capabilities and functionality for optimizing load operations of a hub by automatically generating load plans, according to particular embodiments.

FIG. 2 illustrates a Load Plan Optimization (LPO) System that may be utilized by the system of FIG. 1, according to particular embodiments.

FIG. 3A illustrates a distance matrix that may be generated by the LPO System of FIG. 2, according to particular embodiments.

FIG. 3B illustrates calculating the distances for the distance matrix of FIG. 3A, according to particular embodiments.

FIG. 3C illustrates a penalty matrix that may be generated by the LPO System of FIG. 2, according to particular embodiments.

FIG. 3D illustrates a loads ordering matrix that may be generated by the LPO System of FIG. 2, according to particular embodiments.

FIG. 4 illustrates a peer table that may be used by the LPO System of FIG. 2, according to particular embodiments.

FIG. 5 illustrates calculating car distance penalties by the LPO System of FIG. 2, according to particular embodiments.

FIG. 6 illustrates an example load plan that may be generated by the LPO System of FIG. 2, according to particular embodiments.

FIGS. 7A-7E illustrate various screens of a dashboard that may be generated by the LPO System of FIG. 2, according to particular embodiments.

FIG. 8 is a chart illustrating a method for optimizing load operations of a hub by automatically generating load plans, according to particular embodiments.

FIG. 9 is an example computer system that can be utilized to implement aspects of the various technologies presented herein, according to particular embodiments.

It should be understood that the drawings are not necessarily to scale and that the disclosed embodiments are sometimes illustrated diagrammatically and in partial views. In certain instances, details which are not necessary for an understanding of the disclosed methods and apparatuses or which render other details difficult to perceive may have been omitted. It should be understood, of course, that this disclosure is not limited to the particular embodiments illustrated herein.

DETAILED DESCRIPTION

The disclosure presented in the following written description and the various features and advantageous details thereof, are explained more fully with reference to the non-limiting examples included in the accompanying drawings and as detailed in the description. Descriptions of well-known components have been omitted to not unnecessarily obscure the principal features described herein. The examples used in the following description are intended to facilitate an understanding of the ways in which the disclosure can be implemented and practiced. A person of ordinary skill in the art would read this disclosure to mean that any suitable combination of the functionality or exemplary embodiments below could be combined to achieve the subject matter claimed. The disclosure includes either a representative number of species falling within the scope of the genus or structural features common to the members of the genus so that one of ordinary skill in the art can recognize the members of the genus. Accordingly, these examples should not be construed as limiting the scope of the claims.

A person of ordinary skill in the art would understand that any system claims presented herein encompass all of the elements and limitations disclosed therein, and as such, require that each system claim be viewed as a whole. Any reasonably foreseeable items functionally related to the claims are also relevant. The Examiner, after having obtained a thorough understanding of the disclosure and claims of the present application has searched the prior art as disclosed in patents and other published documents, i.e., nonpatent literature. Therefore, the issuance of this patent is evidence that: the elements and limitations presented in the claims are enabled by the specification and drawings, the issued claims are directed toward patent-eligible subject matter, and the prior art fails to disclose or teach the claims as a whole, such that the issued claims of this patent are patentable under the applicable laws and rules of this country.

Intermodal hub facilities are integral to the logistics and transportation sector, acting as central points for the transfer of goods between various transportation modes, including trains, trucks, and ships. The seamless operation of these hubs is a cornerstone for the uninterrupted flow of goods throughout the supply chain, which is increasingly demanding due to the growth in global trade and the push for faster delivery times.

A core activity within these facilities is the management of inbound and outbound train operations. Trains arrive with containers and trailers—key units in intermodal transport—delivering goods to the hub (inbound) or taking goods away towards their final destinations (outbound). The efficiency of handling these units directly impacts the performance of the hub and the broader supply chain. For example, determining which containers and trailers to load on outbound railcars and how/when to load them is critical to the performance of the hub. Typically, a “load plan” is developed and used to load containers and trailers (i.e., “units”) onto outbound railcars. The load plan is an assignment between units and railcars and typically requires a manual and time-consuming process to generate. Furthermore, the process of generating a load plan requires knowledge of many loading rules related to railcar equipment, unit physical characteristics, service levels, and the like. Given a set of outbound railcars and a list of the candidate units, the quality of a load plan is dependent on factors such as whether units are assigned based on their service levels, loading rules, capacity utilization of the railcars, and distance from a unit parking location to a railcar.

Because load plans are typically manually generated by numerous different coordinators of a hub facility, load plans may lack uniformity, may not always follow required business standards, and may fail to comply with particular loading rules of the hub. This may impact unit security or train safety and may require hub operators to adjust load plans after their generation. This may result in a negative impact to the hub (e.g., a late train departure). Additionally, manually-created load plans may violate unit service priority, cause units to be loaded on wrong outbound trains, and fail to maximize train capacity. This may lead to a delay in unit availability at the destination terminal or impact the unit pickup schedule created by a customer.

To address these and other problems with manually creating load plans for an intermodal hub facility, embodiments of the disclosure provide a load plan optimizer that automatically generates and displays load plans. The load plan optimizer is designed to comply with unit loading rules, to prioritize service levels and sub-service levels, to meet customer expectations, to improve train capacity utilization, and to minimize overall hostler travel distance when moving units from parking lots to tracks. This results in faster track turn-times, lower fuel consumption, reduced CO2 emissions, and improved customer service. By utilizing the load plan optimizer of the disclosed embodiments, hubs are more likely to follow compliance and priority loading rules, thereby reducing or eliminating errors such as units that do not meet customer expectations (e.g., units that are left behind).

In some embodiments, the load plan optimizer consists of three components: terminal digitalization, main optimizer, and insights dashboard. The terminal digitalization module leverages Geographic Information System (GIS) in order to provide current railcar and unit locations as well as the routable distance from a current unit location and desired railcar location. The main optimizer generates and outputs a load plan that indicates which units (e.g., units parked in a parking lot) to select to load on an outbound train, which railcars of the outbound train in which to load the selected units, and positions on the railcars (e.g., which railcar wells) the units should be loaded. The load plan is generated by the main optimizer in order to maximize the train capacity utilization and to minimize the routable distance while following terminal standards such as loading rules and service priority rules. The insights dashboard allows personnel to quickly identify insights and derive actionable tasks regarding load plans. For example, the insights dashboard may include estimated savings including unit traveling distance and fuel usage.

FIG. 1 is a block diagram of an exemplary hub optimization system 100 configured with capabilities and functionality for optimizing load operations of an intermodal hub facility by automatically generating load plans 165, according to certain embodiments of the present disclosure. As shown in FIG. 1, hub optimization system 100 may include a user terminal 130, a hub 140, a network 145, an operations server 125, and a Load Plan Optimization (LPO) system 160. These components, and their individual components, may cooperatively operate to provide functionality in accordance with the discussion herein.

It is noted that the functional blocks, and components thereof, of hub optimization system 100 of embodiments of the present disclosure may be implemented using processors, electronics devices, hardware devices, electronics components, logical circuits, memories, software codes, firmware codes, etc., or any combination thereof. For example, one or more functional blocks, or some portion thereof, may be implemented as discrete gate or transistor logic, discrete hardware components, or combinations thereof configured to provide logic for performing the functions described herein. Additionally, or alternatively, when implemented in software, one or more of the functional blocks, or some portion thereof, may comprise code segments operable upon a processor to provide logic for performing the functions described herein.

It is also noted that various components of hub optimization system 100 are illustrated as single and separate components. However, it will be appreciated that each of the various illustrated components may be implemented as a single component (e.g., a single application, server module, etc.), may be functional components of a single component, or the functionality of these various components may be distributed over multiple devices/components. In such embodiments, the functionality of each respective component may be aggregated from the functionality of multiple modules residing in a single, or in multiple devices.

It is further noted that functionalities described with reference to each of the different functional blocks of hub optimization system 100 described herein is provided for purposes of illustration, rather than by way of limitation and that functionalities described as being provided by different functional blocks may be combined into a single component or may be provided via computing resources disposed in a cloud-based environment accessible over a network, such as one of network 145.

In general, LPO System 160 generates and displays load plans 165 for hub 140. Each load plan 165 indicates assignments between units 161 (e.g., 161A-161I) stored in parking lots 150 (e.g., 150A-150C) and outbound railcars 151 (e.g., 151A-151G). Load plans 165 may be used to efficiently transport specific units 161 from parking lots 150 to locations along tracks 156 (e.g., 156A-156C) where they may be loaded onto railcars 151 for an outbound train 148. To create load plans 165, some embodiments of LPO System 160 utilize a heuristic approach that includes analyzing unit loading constraints and then iterating over railcars 151 and tracks 156 in order determine which units 161 to move to tracks 156 for loading. Furthermore, LPO System 160 may attempt to minimize the distance travelled by hostlers 155 to load units 161 from parking lots 150 and deliver the units 161 to tracks 156 in generating load plans 165. As a result, load plans 165 may be automatically generated and used by hub 140, thereby optimizing and increasing the efficiency of hub 140.

User terminal 130 may include a mobile device, a smartphone, a tablet computing device, a personal computing device, a laptop computing device, a desktop computing device, a computer system of a vehicle, a personal digital assistant (PDA), a smart watch, another type of wired and/or wireless computing device, or any part thereof. In embodiments, user terminal 130 includes an electronic display 132 that may be configured to provide an interface (e.g., a graphical user interface (GUI)) structured to facilitate an operator interacting with hub optimization system 100, e.g., via network 145, to execute and leverage the features provided by hub optimization system 100. In some embodiments, the operator may view and approve and edit load plans 165 generated by LPO System 160. In some embodiments, the operator may be enabled, e.g., through the functionality of user terminal 130, to provide functionality for managing operations of hub 140 in accordance with embodiments of the present disclosure. For example, an operator may provide information related to train schedules, information related to units arriving at hub 140, information related to configuration of the parking lots 150 within hub 140, information related to production track configurations, to request parking spot assignments, to indicate a particular outbound train/train block to load, etc. In an additional or alternative example, the operator may receive information related to parking spot assignments for units 161, etc. User terminal 130 may also be configured to receive and display load plan 165 once generated by LPO System 160.

In some embodiments, the user terminal 130 may be used to send a control signal 290 to a physical asset 135 (e.g., a hostler 155, a crane 153, a chassis 152, etc.), which may cause the physical asset 135 to be automatically actuated and relocate from one location to another. For example, the control signal 290 may instruct the physical asset 135 to move to a specific location based on load plan 165. In embodiments, the user terminal 130 may be configured to communicate with other components of hub optimization system 100, such as via network 145, facilitating the exchange of information and control signals throughout the system. In some embodiments, user terminal 130 may be configured to communicate with other components of hub optimization system 100.

In some embodiments, network 145 may facilitate communications between the various components of hub optimization system 100 (e.g., hub 140, operations server 125, LPO System 160, and/or user terminal 130). Network 145 may include a wired network, a wireless communication network, a cellular network, a cable transmission system, a Local Area Network (LAN), a Wireless LAN (WLAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), the Internet, the Public Switched Telephone Network (PSTN), etc.

Hub 140 may represent any appropriate hub (e.g., an intermodal hub facility, a train station, etc.) in which units 161 are processed as part of the transportation of the units 161. In some embodiments, a unit 161 may include containers, trailers, etc., carrying goods. For example, a unit 161 may include a chassis 152 carrying a container, and/or may include a container. Units 161 (e.g., 161A-161I), including the chassis and the container (e.g., the chassis carrying the container), may be temporarily stored in a parking space 170 (e.g., 170A-170I) of parking lots 150 (e.g., 150A-150C) while the unit 161 awaits being assigned to a railcar 151 of an outbound train 148. Once assigned to an outbound railcar 151 (e.g., 151A-151G), a unit 161 is moved (e.g., by a hostler 155) from its parking spot 170 to tracks 156, where the unit 161 is ultimately loaded or ramped onto the assigned outbound railcar 151 for transportation to the appropriate destination.

Parking lots 150 (e.g., 150A-150C) may be used to park or store units 161 while units 161 are waiting to be assigned to and loaded onto railcars 151. Parking lots 150 of hub 140 may include numerous parking spots 170 (e.g., 170A-170I). In some embodiments, parking lots 150 may represent physical parking lots that may be configured with a particular layout and orientation with respect to tracks 156 of hub 140. Furthermore, parking lots 150 may each be located different distances from tracks 156. During operations, certain embodiments of LPO System 160 consider physical driving distances that a hostler 155 would have to travel from parking spots 170 to locations along tracks 156 in generating optimized load plans 165.

Chassis 152 (e.g., including, trucks, forklifts, and/or any structure configured to securely carry a container), and operators of chassis 152, may be used to securely carry units within hub 140. Hostlers 155 (e.g., including hostler operators, etc.) may be used to transport or move units 161 (e.g., containers on chassis) within hub 140, such as moving units 161 to be loaded onto outbound railcars 151. Cranes 153 may be used to load units 161 onto departing trains (e.g., to unload units 161 from chassis 152 and load units 161 onto railcars 151 of departing trains 148). Railcars 151 may be used to transport the units within train 148. For example, train 148 may be composed of one or more railcars 151, and units 161 may be loaded onto railcars 151 (e.g., within wells of railcars 151) for transportation. Railcars 151 may be assembled together to form train 148. Locomotives 154 may include engines that may be used to power train 148. Other resources 157 may include other resources not explicitly mentioned herein but configured to allow or facilitate units to be processed through hub 140.

The physical asset 135 may represent a variety of railroad network assets that can be mobilized or relocated in response to load plan 165 generated by LPO System 160. These physical assets may include, but are not limited to, locomotives 154, hostlers 155, trucks, cranes 153, loading equipment, or any other movable equipment used in rail transportation operations. In some embodiments, the physical asset 135 may be capable of receiving and responding to control signals 290 generated based on load plan 165. In some embodiments, these control signals 290 may be used to automatically actuate the physical asset 135, causing it to move from one location to another. For example, a control signal 290 may instruct a hostler 155 to retrieve a unit 161 and deliver it to a specific trackside location according to load plan 165. Alternatively, the control signals 290 may be used to guide manual operation of the physical asset 135, with operators using the information to make informed decisions about asset positioning and relocation.

In embodiments, operations server 125 may be configured to provide functionality for facilitating operations of hub 140. In embodiments, operations server 125 may include data and information related to operations of hub 140, such as current inventory of all hub resources (e.g., chassis 152, hostlers 155, drivers, lift capacity, parking lots 150 and parking spaces 1770, railcars 151, locomotives 154, tracks 156, etc.). This hub resource information included in operations server 125 may change over time as resources are consumed, replaced, and/or replenished, and operations server 125 may have functionality to update the information.

Operations server 125 may include data and information related to inbound and/or outbound train schedules (e.g., arriving times, departure times, destinations, origins, capacity, available spots, inventory list of units for outbound trains, etc.). With respect to outbound train schedules, the outbound train schedules may provide information related to outbound trains that are scheduled to depart from the hub during a planning horizon, including scheduled departure time, capacity of the outbound train, a list of units already scheduled to be loaded onto the outbound train, destination of the outbound train, etc. In some embodiments, the information from operations server 125 may be used (e.g., by LPO System 160) to develop, generate, and/or update load plans 165.

In general, LPO System 160 accesses various hub data and preferences as inputs and generates/displays load plans 165 based on the inputs. Load plans 165 generally provide assignments of units 161 to railcars 151 for a selected outbound train 148 and may be automatically generated based on priority (e.g., service levels, etc.) and to maximize efficiency of hub 140 (e.g., to minimize distances hostler 155 must travel). A particular embodiment of LPO System 160 is illustrated in FIG. 2. As shown in FIG. 2, LPO System 160 may be implemented in a server (e.g., server 110). In some embodiments, the functionality of server 110 to facilitate operations of LPO System 160 may be provided by the cooperative operation of the various components of server 110, as will be described in more detail below.

In some embodiments, LPO System 160 may send one or more electronic alerts 166 (e.g., a text message and the like) to user terminal 130 (e.g., a smartphone, a computer, a tablet, etc.) to notify the user of load plan 165. For example, LPO System 160 may send an alert 166 or notification to user terminal 130 to notify a user of the completion of load plan 165 and/or to notify the user of specific unit-to-railcar assignments from load plan 165. A user may view alert 166 and take any appropriate action (e.g., view load plan 165, operate hostler 155 in order to move a unit 161 to a trackside location according to load plan 165, etc.). As a result, the efficiency of hub 140 may be further improved.

It is noted that although FIG. 2 shows server 110 as a single server, it will be appreciated that server 110 (and the individual functional blocks of server 110) may be implemented as separate devices and/or may be distributed over multiple devices having their own processing resources, whose aggregate functionality may be configured to perform operations in accordance with the present disclosure. Furthermore, those of skill in the art would recognize that although FIG. 2 illustrates components of server 110 as single and separate blocks, each of the various components of server 110 may be a single component (e.g., a single application, server module, etc.), may be functional components of a same component, or the functionality may be distributed over multiple devices/components. In such embodiments, the functionality of each respective component may be aggregated from the functionality of multiple modules residing in a single, or in multiple devices. In addition, particular functionality described for a particular component of server 110 may actually be part of a different component of server 110, and as such, the description of the particular functionality described for the particular component of server 110 is for illustrative purposes and not limiting in any way.

As shown in FIG. 2, server 110 includes processor 111 and memory 112. Processor 111 may include a processor, a microprocessor, a controller, a microcontroller, a plurality of microprocessors, an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), or any combination thereof, and may be configured to execute instructions to perform operations in accordance with the disclosure herein. In some embodiments, implementations of processor 111 may comprise code segments (e.g., software, firmware, and/or hardware logic) executable in hardware, such as a processor, to perform the tasks and functions described herein. In yet other embodiments, processor 111 may be implemented as a combination of hardware and software. Processor 111 may be communicatively coupled to memory 112.

Memory 112 may comprise one or more semiconductor memory devices, read only memory (ROM) devices, random access memory (RAM) devices, one or more hard disk drives (HDDs), flash memory devices, solid state drives (SSDs), erasable ROM (EROM), compact disk ROM (CD-ROM), optical disks, other devices configured to store data in a persistent or non-persistent state, network memory, cloud memory, local memory, or a combination of different memory devices. Memory 112 may comprise a processor readable medium configured to store one or more instruction sets (e.g., software, firmware, etc.) which, when executed by a processor (e.g., one or more processors of processor 111), perform tasks and functions as described herein.

Memory 112 may also be configured to facilitate storage operations. For example, memory 112 may comprise database 114 for storing various information related to operations of hub optimization system 100. For example, database 114 may store configuration information related to operations of LPO System 160. In embodiments, database 114 may store information related to various models used during operations of LPO System 160. Database 114 is illustrated as integrated into memory 112, but in some embodiments, database 114 may be provided as a separate storage module or may be provided as a cloud-based storage module. Additionally, or alternatively, database 114 may be a single database, or may be a distributed database implemented over a plurality of database modules.

In some embodiments, memory 112 stores load plan optimizer 210. Load plan optimizer 210 may be a software module/application utilized by LPO System 160 to provide load plans 165 for efficiently loading units 161 onto railcars 151 in hub 140 (e.g., to minimize distances hostler 155 must travel and to meet load priority rules). Load plan optimizer 210 represents any suitable set of instructions, logic, or code embodied in a computer-readable storage medium. For example, load plan optimizer 210 may be embodied in memory 112, a disk, a CD, or a flash drive. In particular embodiments, load plan optimizer 210 may include instructions (e.g., a software application) executable by a computer processor to perform some or all of the functions described herein. In some embodiments, load plan optimizer 210 includes data bifurcation module 220, distance module 230, track order module 240, cars extra distance module 250, nearest unit approach module 260, main optimization module 270, and post processing module 280, which are described in more detail herein.

In some embodiments, load plan optimizer 210 includes data bifurcation module 220. In general, data bifurcation module 220 receives or otherwise accesses train data 225 for hub 140. In some embodiments, train data 225 includes a list of units 161 currently in hub 140 and metadata associated with each unit 161. For example, the metadata for each unit 161 may include unit type, unit weight, unit priority, etc. In some embodiments, train data 225 includes all the railcars 151 that are currently located on production loading tracks 156 and metadata associated with each railcar 151. The metadata for each railcars 151 may include, for example, the type of railcar 151 (e.g., flatcar, refrigerator car, etc.) and a number of wells (i.e., spots for units 161) available on each railcar 151.

In some embodiments, data bifurcation module 220 also receives or otherwise access user preferences 227. For example, the user preferences 227 may include an identification of a particular train or train block to use for load plan 165 (i.e., which train or train block to build), an indication of whether or not an empty unit 161 may be placed on another empty unit 161, and which end to load train 148 (e.g., north end, south end, etc.). In some embodiments, data bifurcation module 220 determines a subset of units 161 for consideration (e.g., eligible units 161). For example, if hub 140 includes a total of 2500 units 161 and a user selects a particular outbound train to build, data bifurcation module 220 may determine that only 200 units 161 could be placed on the outbound train since those 200 units have a destination that matches the destination/capacity of the outbound train. Once the subset of units 161 is determined, LPO System 160 may determine the specific selection and assignment of that subset of units 161 to load on the outbound train (e.g., according to priority rules such as service levels, in-gate time, goal time, etc.).

In some embodiments, the operations of data bifurcation module 220 can be summarized as the following:

• • Retrieve train data 225 (e.g., one month of data).
  • Retrieve user preferences 227 (e.g., a selection of a train 148 or train block to build).
  • Divide the data into loads and cars with corresponding fields.
  • Determine eligible (e.g., subset) units 161.

In some embodiments, load plan optimizer 210 includes distance module 230. In general, distance module 230 receives or otherwise accesses distance data 235 and generates distance matrix 237 as illustrated in FIG. 3A. Distance data 235 indicates an actual driven distance from every possible parking spot 170 to every possible spot along tracks 156 (or to a specific end of tracks 156). Distance module determines, for each particular unit 161 under consideration (e.g., eligible units from data bifurcation module 220), a driving distance (e.g., in feet) from the parking spot 170 of each particular unit 161 to a specific location along track 156 and records the distance in distance matrix 237. For example, as illustrated in FIG. 3B, distance module 230 analyzes distance data 235 to determine the following distances for unit “3” in Lot A to the East ends of tracks 156: 1208 feet from the parking spot of unit 3 in Lot A to the East end of track 156A; 876 feet from the parking spot of unit 3 in Lot A to the East end of track 156B; 1376 feet from the parking spot of unit 3 in Lot A to the East end of track 156C; and 2208 feet from the parking spot 170 of unit 3 in Lot A to the East end of track 156D. Distance module 230 iterates through this process for each unit 161 under consideration (e.g., Units 1-5 in the example of FIG. 3B) and records the distances in distance matrix 237. Distance module 230 may then calculate a “Sum” by adding the distances for Units 1-5 for each track as illustrated in FIG. 3A.

In some embodiments, distance module 230 estimates locations of railcars 151 along tracks 156. To do so, distance module 230 may first determine a length of each railcar 151 on track 156 and/or a number of wells of each railcar 151. In some embodiments, distance module 230 determines an approximate GPS location of each well of each railcar 151. In some embodiments, the operations of distance module 230 can be summarized as the following:

• • Determine driving distances (e.g., for hostlers 155) from parking spots 170 to specific locations along tracks 156 for subset of units 161 (concerned units 161) using distance data 235 (may estimate locations of railcars 151 for a selected outbound train).
  • If distances for each particular lot, row, spot are available, determine rounded up distance directly from distance data 235.
  • If distances for each particular lot, row, spot are not available, determine an average distance for lot and row combination.

In some embodiments, load plan optimizer 210 includes track order module 240. In general, track order module 240 arranges the tracks in distance matrix 237 in ascending order with respect to the Sum of distance of all loads to a track. For example, as illustrated in FIG. 3A, track order module 240 analyzes the “Sum” row in distance matrix 237 and arranges tracks 156A, 156B, 156C, and 156D in ascending order 245. In this particular example, track 156A with a total distance of 5804 is labeled as Rank 1, track 156B with a total distance of 6354 is labeled as Rank 2, track 156D with a total distance of 9686 is labeled as Rank 3, and track 156C with a total distance of 9972 is labeled as Rank 4. In some embodiments, if there are 20 ft/28 ft loads (i.e., units 161 that are 20 ft/28 ft long), track order module 240 may separately calculate distances from parking spots 170 to tracks 156 and then alter the order accordingly (e.g., if there are 20 ft/28 ft loads nearer to any track, prioritize filling for the track).

In some embodiments, load plan optimizer 210 utilizes a penalty model for determining load ordering. For example, FIG. 3C illustrates a penalty matrix 310 that may be utilized to determine load ordering using a penalty model. In these embodiments, load plan optimizer 210 may first determine the rank for each track 156 as compared to the other tracks 156 for each load. Next, some embodiments of load plan optimizer 210 may calculate a penalty for each track. The penalty may be calculated by subtracting the current distance from the next higher distance. For example, the penalty for Track 156A for Unit 161A may be calculated by subtracting 2695 from 3628 to arrive at a penalty amount of 933 as illustrated in penalty matrix 310. In some embodiments, the implication for the penalty may be the extra distance (e.g., in feet) it would cost to move the unit 161 if the unit 161 is not placed in the current location. Next, some embodiments of load plan optimizer 210 may iterate this process on the track order list. Load plan optimizer 210 may then sort the rank columns of penalty matrix 310 in ascending order by rank and may sort the penalty columns of penalty matrix 310 in descending order by penalty amount in order to determine the final load ordering.

FIG. 3D illustrates an examples of a loads ordering matrix 320A and a loads ordering matrix 320B that may be utilized by load plan optimizer 210 to determine load ordering. As illustrated in loads ordering matrix 320A, load plan optimizer 210 may first determine a preferred track segment for each load. Next, load plan optimizer 210 may order by preferred track 156 followed by other tracks 156 as indicated by arrow 321. Next, load plan optimizer 210 may order by distance to the track 156 as indicated by arrows 322. Finally, as illustrated in loads ordering matrix 320B, load plan optimizer 210 may repeat the above process with the remaining tracks 156 after all railcars 151 of the track 156 are filled. In the specific example of loads ordering matrix 320B, it is assumed that Unit 1 and Unit 3 are allocated to track 156A.

In some embodiments, it may be desirable to double-stack units 161 on railcars 151. To aid in this process, some embodiments of LPO System 160 utilize a peer table 400 as illustrated in FIG. 4. In general, peer table 400 indicates possible top/bottom stacking combinations for all possible types of units 161 (e.g., load compliance rules for stacking units 161 on railcars 151). In this particular example of peer table 400, the first column indicates which type of unit 161 is stacked on the bottom of railcars 151 and the second column indicates which type of unit 161 could possibly be stacked on the top. The third column indicates whether or not the stacking combination in the first two columns is possible (e.g., a “0” indicates that the stacking combination is not possible and a “1” indicates the stacking combination is possible). In this particular example, the first row indicates that the combination of a 20-foot standard container 161 (“20 Standard K”) placed on the bottom and a 20-foot standard container 161 (“20 Standard K”) placed on the top is not a possible stacking combination. Similarly, the second row indicates that the combination of a 20-foot standard container 161 (“20 Standard K”) placed on the bottom and a 40-foot standard container 161 (“40 Standard K”) placed on the top is a possible stacking combination. In some embodiments, peer table 400 may be generated based on the subset of units 161 as determined by data bifurcation module 220 or the inventory of units 161 within hub 140. Utilizing peer table 400 may improve computational time of LPO System 160 to generate load plan 165.

In some embodiments, load plan optimizer 210 includes cars extra distance module 250. In some embodiments, distance data 235 indicates a specific driving distance from each parking spot 170 to every possible location of railcar 151 (or well of railcar 151) along tracks 156. In these embodiments, cars extra distance module 250 may not be utilized. However, in other embodiments, distance data 235 may only indicate driving distances from parking spots 170 to specific ends of tracks 156 (e.g., north end). In these embodiments where distance data 235 only indicates driving distances from parking spots 170 to specific ends of tracks 156, cars extra distance module 250 may be utilized to determine incremental penalties for selecting different railcars 151 on tracks 156. For example, as illustrated in FIG. 5, cars extra distance module 250 determines the extra distance penalties for moving Unit 3 from Lot A to the various railcars 151 (i.e., railcars A-D) of track 156B. In this example and as illustrated in table 500 of FIG. 5, railcar A has a length of 100, railcar B has a length of 200, railcar C has a length of 300, and railcar D has a length of 400. If Unit 3 is moved from Lot A to railcar A on the East end of track 156B, the penalty (i.e., “XTRA_DIST”) is 0 feet since the length of railcar A does not need to be traversed. If Unit 3 is moved from Lot A to the railcar B, the penalty is 100 feet since the length of railcar A must be traversed. If Unit 3 is moved from Lot A to the railcar C, the penalty is 300 feet since the lengths of railcars A and B must be traversed. If Unit 3 is moved from Lot A to the railcar D, the penalty is 600 feet since the lengths of railcars A, B, and C must be traversed. In some embodiments, the operations of cars extra distance module 250 can be summarized as the following:

• • Order cars in a track.
  • Get cumulative sum of distance for cars.
  • Calculate well load limit using carload limit and number of platforms.

In some embodiments, load plan optimizer 210 includes nearest unit approach module 260. In some embodiments, nearest unit approach module 260 estimates a number of available spots on the selected outbound train. For example, nearest unit approach module 260 may determine a number of railcars 151 in the outbound train and then estimate the number of well locations of each railcar 151 based on the types of railcars 151 in the outbound train. If, for example, railcars 151 of the outbound train each have two wells and there are ten railcars 151 (for a total of 20 wells), nearest unit approach module 260 determines that forty units 161 can be loaded on the outbound train if the units are double stacked. The top forty units of the subset of units 161 may then be selected based on priority, load compliance rules (e.g., peer table 400), and driving distances of hostler 155. In some embodiments, the operations of nearest unit approach module 260 can be summarized as the following:

• • For every load, the nearest track is marked as “1” and rest as “2”: Group Track.
  • Loads are ordered by Group Track and then distance from track.
  • After every iteration, repeat with remaining tracks.

In some embodiments, load plan optimizer 210 includes main optimization module 270. In general, main optimization module 270 assigns units 161 to railcars 151 of a selected outbound train based on the operation of data bifurcation module 220, distance module 230, track order module 240, and nearest unit approach module 260, as described above. In some embodiments, main optimization module 270 iterates over tracks 156 using the order established by track order module 240. In some embodiments, main optimization module 270 begins assigning units 161 to railcars 151 from a specific end (e.g., north end or south end) of railcars 151 based on user preferences. For example, if the user selects to build from the north end of tracks 156, main optimization module 270 determines the railcar 151 closest to the north end of tracks 156 and begins assigning units 161 to that railcar 151. For each railcar 151, main optimization module 270 may determine a number of available wells, a size/length of each available well, a weight limit of each well, etc. Main optimization module 270 then begins going down the list of available units 161 (e.g., sorted by priority) to determine which units 161 will match with the first available well of the first railcar (e.g., according to the size and weight limit of the well). These feasible units 161 that match with the available wells may then be sorted by driving distance. In some embodiments, main optimization module 270 assigns units 161 to railcars 151 in an order that is based on the type of railcar 151. For example, all container railcars 151 are assigned first (“K cars” having multiple wells) and then hitch railcars (“TTRX” and “TTAX” railcars having flat surfaces with only a single well) are assigned after the container railcars. In some embodiments, the operations of main optimization module 270 can be summarized as the following:

• • Iterate over tracks using track order in order.
  • Iterate over cars from a specific end of track (e.g., north end).
  • Fill well cars 151 first, then flatcars 151 (e.g., “TTRX” and “TTAX” cars 151).
  • Every function accepts a car at a time and returns assignment and remaining loads.

In some embodiments, load plan optimizer 210 (e.g., via main optimization module 270) can utilize the following model to assign units 161 to railcars 151:

Min ⁢ ∑ i ∈ U ∑ j ∈ W ∑ k ∈ K ∑ p ∈ P d i ⁢ j ⁢ x i ⁢ j ⁢ k ⁢ p + ∑ j ∈ W s j + ∑ i ∈ U ⁢ ❘ "\[LeftBracketingBar]" h i = 1 ∑ r ∈ R h 1 ⁢ 0 ⁢ 0 ⁢ 0 ⁢ 0 ⁢ z i ⁢ r + 
 ∑ j ∈ W f ∑ k ∈ K j f 1 ⁢ 0 ⁢ 0 ⁢ y j ⁢ k + ∑ j ∈ W 4 ⁢ 0 | p ⁢ n j ∈ { 2 , 4 } ∑ k ∈ K j o 1 ⁢ 0 ⁢ 0 ⁢ y j ⁢ k + 
 ∑ j ∈ W 4 ⁢ 8 ⁢ ❘ "\[LeftBracketingBar]" pn j ∈ { 2 , 4 } ∑ k ∈ K j o 1 ⁢ 0 ⁢ 0 ⁢ y j ⁢ k

Using this model, load plan optimizer 210 attempts to minimize: total distance+top/bottom weight slack+hazmat units in 15-well distance from track head+FOD penalty+penalty for 45′ over 40′ in 40 ft wells in positions 2, 4+penalty for 53′ over 40′ or 45′ in 48 ft wells in positions 2,4. In some embodiments, load plan optimizer 210 utilizes the set notations as shown in TABLE 1 below for this model:

TABLE 1
Set Notations
U: Set of units 161
R: Set of railcars 151
Rh: Set of railcars 151 within 15-well distance from the head.
R3*: Set of 3-well double stack railcars 151 with well length < 53’
R5*: Set of 5-well double stack railcars 151 with well length < 53’
W: Set of wells/platforms
W40: Set of 40’ wells/platforms in railcars 151 with > 2 wells
W45: Set of 45’ wells/platforms in railcars 151 with > 2 wells
W48: Set of 48’ wells/platforms in railcars 151 with > 2 wells
Wf : Set of wells/platforms that can load both containers and trailers
Wr: Set of wells/platforms in railcar r
K: Set of loading patterns
Kj: Set of loading patterns eligible for well j
K j d : Set ⁢ of ⁢ double ⁢ stack ⁢ loading ⁢ patterns ⁢ eligible ⁢ for ⁢ well ⁢ j
K j 5 ⁢ 3 : Set ⁢ of ⁢ double ⁢ stack ⁢ loading ⁢ patterns ⁢ eligible ⁢ for ⁢ well ⁢ j ⁢ where ⁢ top ⁢ container ⁢ is ⁢ 53 ’ ⁢ and ⁢ bottom ⁢ is ⁢ 40 ’ ⁢ or ⁢ 45 ’
K j f : Set ⁢ of ⁢ FOD ⁢ loading ⁢ patterns ⁢ eligible ⁢ for ⁢ well ⁢ j
K j o : Set ⁢ of ⁢ double ⁢ stack ⁢ loading ⁢ patterns ⁢ eligible ⁢ for ⁢ well ⁢ j ⁢ where ⁢ top ⁢ unit ’ ⁢ s ⁢ length > bottom ⁢ unit ’ ⁢ s ⁢ length
P: Set of positions (1 = bottom, 2 = top)
Pk: Set of positions in pattern k
T: Types of units 161 (K = Container, V = Trailer)
Tk: Type of units 161 in pattern k
Lt: Length of units 161 in type t. LK = {20, 40, 45, 53}; LV = {28, 40, 45, 48, 53}

In some embodiments, load plan optimizer 210 utilizes some or all of the input parameters as shown in TABLE 2 below:

TABLE 2
Parameters

	dij: distance from parking location of unit i to location of well j
	ntlkp: Number of units of type t and size l in pattern k at position p
	li: length of unit i
	ci: Type of unit i
	bi: Weight of unit i
	maxBj: Maximum allowed weight for well j
	maxBr: Maximum allowed weight for railcar r
	hi: 1, if unit i is hazmat; 0 otherwise.
	hti: 1, if unit i is tank; 0 otherwise.
	hvi: 1, if unit i is high value; 0 otherwise.
	pnj: platform number of well j.

In some embodiments, load plan optimizer 210 utilizes some or all of the variables as shown in TABLE 3 below:

TABLE 3
Variables

xijkp: 1, if unit i is loaded on well j using loading pattern k at position

p; 0 otherwise.

yjk: 1, if well j is loaded with pattern k; 0 otherwise.

zir: 1, if unit i is assigned to railcar r; 0 otherwise.

wr: 1, if railcar r is used; 0 otherwise.

sj: Slack variable for top/bottom weight control in well j (non-negative)

(optional).

In some embodiments, load plan optimizer 210 utilizes one or more constraints as shown in TABLE 4 below:

TABLE 4
Constraints

All units 161 must be assigned (after POC it will be max units with min railcars 151).

∑ r ∈ R z ir = 1 ∀ i ∈ U

If unit 161 is loaded on railcar 151, it must use a unique well, unique pattern, and

unique position.

∑ j ∈ W r ∑ k ∈ K j ∑ p ∈ P k x ijkp = z ir ∀ i ∈ U , r ∈ R

Matching patterns at the position/length level.

∑ i ∈ U | c i = t , l i = l x ijkp = n tlkp ⁢ y jk ∀ j ∈ W , k ∈ K j , p ∈ P k , t ∈ T p , l ∈ L t

Overall well pattern matching.

∑ i ∈ U ∑ p ∈ P k x ijkp = ( ∑ p ∈ P k ∑ t ∈ T k ∑ l ∈ L t n tlkp ) ⁢ y jk ∀ j ∈ W , k ∈ K j

If a railcar 151 is loaded, each of its wells/platforms must be loaded with at most one

pattern.

∑ k ∈ K j y jk ≤ w r ∀ r ∈ R , j ∈ W r

Max well weight.

∑ i ∈ U ∑ k ∈ K j ∑ p ∈ P k b i ⁢ x ijkp ≤ max ⁢ B j ∀ j ∈ W

Max railcar 151 weight.

∑ i ∈ U b i ⁢ z ir ≤ max ⁢ B r ∀ r ∈ R

Top/bottom weight control (only for patterns with double stack).

∑ i ∈ U ∑ k ∈ K j b i ⁢ x ijkt ≤ 1 . 2 * ∑ i ∈ U ∑ k ∈ K j b i ⁢ x ijkb ∀ j ∈ W , t = top , b = bottom

∑ i ∈ U ∑ k ∈ K j b i ⁢ x ijkt ≤ 0 . 8 * ∑ i ∈ U ∑ k ∈ K j b i ⁢ x ijkb + s j ∀ j ∈ W , t = top , b = bottom ⁢ ( Optional )

s j ≤ 0 . 4 * ∑ i ∈ U ∑ k ∈ K j b i ⁢ x ijkb ∀ j ∈ W , b = bottom ⁢ ( Optional )

Special constraints for Hazmat units 161. (a) if unit 161 is tank (assumed hazmat), then

it cannot be loaded on a double stack pattern. (b) If unit 161 is hazmat but no tank, then

if loaded on double stack it cannot be at the bottom.

∑ j ∈ W ∑ k ∈ K j d ∑ p ∈ P x ijkp = 0 ∀ i ∈ U ⁢ ❘ "\[LeftBracketingBar]" ht i = 1

∑ j ∈ W ∑ k ∈ K j d x ijk ⁢ 1 = 0 ∀ i ∈ U ⁢ ❘ "\[LeftBracketingBar]" h i = 1 ⋀ ht i = 0

Special constraints for high-value units 161. If using a double stack pattern, cannot be

loaded at the top.

∑ j ∈ W ∑ k ∈ K j d x ijk ⁢ 2 = 0 ∀ i ∈ U ⁢ ❘ "\[LeftBracketingBar]" hv i = 1

Special constraints for 3-well and 5-well railcars 151 with units 161 on top larger than

well length

∑ k ∈ K j o y jk ≤ 1 - ∑ k ∈ K j d y mk ∀ r ⁢ ϵ ⁢ R 3 * ⋃ R 5 * , j ⁢ ϵ ⁢ W r ⁢ ❘ "\[LeftBracketingBar]" pn j ⁢ in ⁢ { 1 , 3 } , m ⁢ ϵ ⁢ W r ❘ "\[RightBracketingBar]" ⁢ pn m ⁢ in ⁢ { 2 }

∑ k ∈ K j o y jk ≤ 1 - ∑ k ∈ K j d y mk ∀ r ⁢ ϵ ⁢ R 5 * , j ⁢ ϵ ⁢ W r ⁢ ❘ "\[LeftBracketingBar]" pn j ⁢ in ⁢ { 3 , 5 } , m ⁢ ϵ ⁢ W r ❘ "\[RightBracketingBar]" ⁢ pn m ⁢ in ⁢ { 4 }

∑ j ∈ W 4 ⁢ 0 ⋃ W 4 ⁢ 5 | pn j ∈ { 2 , 4 } ∑ k ∈ K j 53 y jk = 0

Units cannot be assigned to railcars 151 that have not been selected.

zir ≤ wr ∀i ∈ U, r ∈ R

In some embodiments, load plan optimizer 210 may assign units 161 to well cars 151 (e.g., “K” cars that can carry containers only and can carry stacked containers) using the following rules. First, load plan optimizer 210 may fill 20 ft units 161 in well cars 151 on the nearest track 156. Next, load plan optimizer 210 may stack non-20 ft units 161 on top of the filled well cars. Finally, load plan optimizer 210 may try non-20 ft units 161 in pairs in order to check stacking possibilities.

In some embodiments, load plan optimizer 210 may assign units 161 to well cars 151 (e.g., “K” cars that can carry containers only and can carry stacked containers) using the following rules. First, load plan optimizer 210 may fill 20 ft units 161 in well cars 151 on the nearest track 156. Next, load plan optimizer 210 may stack non-20 ft units 161 on top of the filled well cars. Finally, load plan optimizer 210 may try non-20 ft units 161 in pairs in order to check stacking possibilities.

In some embodiments, load plan optimizer 210 may assign units 161 to “TTRX” cars 151 (e.g., a type of flatcar that can carry both containers and trailers and can hold two 20 ft/28 ft units 161 together in a platform) using the following rules. First, load plan optimizer 210 may try to fill TTRX cars 151 using pairs of 20 ft/28 ft units 161. Finally, load plan optimizer 210 may try to fill TTRX cars 151 using one non-20 ft unit 161 at a time.

In some embodiments, load plan optimizer 210 may assign units 161 to “TTAX” cars 151. TTAX cars 151 are a type of flatcar that can carry both containers and trailers and can hold only one unit 161 irrespective of size. To assign units 161 to TTAX cars 151, load plan optimizer 210 may try one unit 161 at a time irrespective of size. In some embodiments, for all types of cars 151 (e.g., well cars 151, TTRX cars 151, and TTAX cars 151), load plan optimizer 210 may consult additional universal stacking rules. For example, load plan optimizer 210 may match a size limit, may check a weight limit, may limit hazardous units 161 to always being on top, to avoid topping a tank unit 161 with another unit 161, and to place high-value units 161 on the bottom.

In some embodiments, some units 161 may be labeled as “difficult” units. For example, a unit 161 that is a military tank may be labeled as a difficult unit 161. In general, difficult units 161 must remain as single units (i.e., difficult units cannot be stacked on other units, and no other units may be stacked on difficult units). In some embodiments, units 161 that are labeled as difficult units may be prioritized by main optimization module 270 over other units 161.

In some embodiments, load plan optimizer 210 includes post processing module 280. In some embodiments, the operations of post processing module 280 can be summarized as the following:

• • Identify cars 151 with only well A filled.
  • Remove top unit from well A and place in B, if stacked.
  • Else keep checking the next nearest unit 161 with weight, length, and other essential conditions matching to fill well B.

In some embodiments, post processing module 280 may perform a stacking check after units 161 have been assigned to railcars 151. For example, post processing module 280 may analyze the assigned stacking of units 161 on articulated well cars (e.g., three-unit or five-unit articulated well cars) against predetermined stacking rules. As a first example, a first stacking rule may be that the length of a unit 161 stacked on top of another unit 161 in a first well (e.g., well A) plus the length of a unit 161 stacked on top of another unit 161 in an adjacent well (e.g., well B) must be less than or equal to twice the length of the wells of the well car 151. If the length of a unit 161 stacked on top in a first well plus the length of a unit 161 stacked on top in an adjacent well is greater than twice the length of the wells of the well car 151, post processing module 280 may send one or more instructions or signals to remove a unit 161 stacked on top in a third well (e.g., well C) and add the unit back to the loads list. As a specific example, if each well of a well car 151 is 20 feet long, the length of a unit 161 stacked on top of another unit 161 in well A is 22 feet, and the length of a unit 161 stacked on top of another unit 161 in well B is 22 feet, post processing module 280 may send one or more instructions or signals to remove a unit 161 stacked on top of another unit 161 in well C and add the unit back to the loads list (i.e., 22 feet+22 feet>2×20 feet).

As a second example, a second stacking rule that may be utilized by post processing module 280 to perform a stacking check may be that a train 148 may have completely empty well cars 151 and that the train 148 should have well cars 151 where at least end wells are filled. As a third example, a third stacking rule that may be utilized by post processing module 280 to perform a stacking check may be that a train 148 cannot have completely empty well cars 151 and that the train 148 should have well cars 151 where at least end wells are filled. As a fourth example, a fourth stacking rule that may be utilized by post processing module 280 to perform a stacking check may be that a train 148 should have well cars 151 that have all wells filled.

In some embodiments, load plan optimizer 210 may utilize certain rules that apply to certain types of units 161. For example, rules for hazmat units 161 may be that non-tank hazmat units 161 must be placed on top of another unit 161, and hazmat units 161 that are tank units must be placed on the bottom with no other units 161 on top. Another rule for hazmat units 161 may be that hazmat units 161 must be a certain number of wells (e.g., fifteen) behind the head of the train. As another example, a rule for high-value units may be that all high-value units 161 must only be placed on the bottom (i.e., not on top of another unit 161).

In some embodiments, load plan optimizer 210 may utilize certain rules that apply to all types of railcars 151 irrespective of type. For example, a first rule for all railcars 151 may be that a total weight limit for the railcar 151 and any included units 161 must not exceed a weight limit. A second rule for all railcars 151 may be that the bottom row of wells must be completely filled for the first certain number of wells (e.g., the first fifteen wells). A third rule for all railcars 151 may be that a trailer unit 161 may not be placed in a well railcar 151. A fourth rule for all railcars 151 may be that a trailer unit 161 that is 53 feet long may not be placed in a small well of a well railcar 151.

In some embodiments, load plan optimizer 210 may utilize certain rules that apply to well railcars 151. A first rule utilized by load plan optimizer 210 for well railcars 151 may be that double-stacking is permitted only in well cars 151. A second rule utilized by load plan optimizer 210 for well railcars 151 may be that containers on the bottom row of the well railcar 151 must be less than or equal to the well length. A third rule utilized by load plan optimizer 210 for well railcars 151 may be that longer containers are placed on the top row. For example, if the top row containers are longer than 40 ft on a small well, only odd numbered wells (e.g., 1, 3, & 5) may be filled. A fourth rule utilized by load plan optimizer 210 for well railcars 151 may be that 20 ft units 161 may only be placed on the bottom row of well railcars 151 and that a well railcar 151 must have two 20 ft units 161 before loading any units 161 on the top row. A fifth rule utilized by load plan optimizer 210 for well railcars 151 may be that the weight of a top container 161 must be less than or equal to a certain percentage (e.g., 120%) of the weight of the bottom container 161.

In some embodiments, load plan optimizer 210 may utilize certain rules that apply to flat railcars 151 (e.g., TTRX and TTAX railcars 161). A first rule utilized by load plan optimizer 210 for flat railcars 151 may be that a trailer must be attached to at least a lead hitch if multiple hitches are utilized. A second rule utilized by load plan optimizer 210 for flat railcars 151 may be that two 28 ft units 161 are allowed on multi-hitch cars only. A third rule utilized by load plan optimizer 210 for flat railcars 151 may be that containers 161 may be placed on flat cars, single stacked, but that double-stacked is preferred.

In some embodiments, load plan optimizer 210 may utilize a priority hierarchy in case of conflicts of loading/stacking rules for units 161. For example, load plan optimizer 210 may utilize the following priority hierarchy in case of conflicts: service level, earliest arrival time, closest goal time, matching unit types, distance, and then traffic flows. Load plan optimizer 210 may utilize any order of these or other factors in case of conflicts of loading/stacking rules for units 161.

In some embodiments, LPO System 160 includes an asset control manager 124 that is configured to generate and send control signals 290 for managing and operating one or more physical assets 135 based on load plan 165 generated by LPO System 160. In embodiments, the asset control manager 124 may analyze load plans 165, which include assignments of units 161 to railcars 151, to determine optimal timing and positioning for the physical asset 135 and may generate the control signals based on the analysis.

The control signals 290 generated by the asset control manager 124 may be electronic instructions or commands sent to the physical asset 135. These signals may contain specific directives for movement, operation, or positioning of the asset. In some embodiments, control signals 290 may be transmitted wirelessly or through a wired connection (e.g., via network 145), depending on the communication capabilities of the physical asset 135.

The physical asset 135 may represent various types of equipment used in rail operations, such as locomotives 154, hostlers 155, cranes 153, or other machinery involved in loading, unloading, or moving freight such as units 161. These assets may be equipped with actuators, motors, or other mechanisms that allow them to move or operate (either autonomously or via user input) in response to the received control signals 290.

In some cases, the asset control manager 124 may use load plan 165 to generate a control signal 290 that instructs the physical asset 135 to move from one location to another. This movement may be based on the assignments of units 161 to railcars 151 as provided by load plan 165. For example, if load plan 165 indicates that unit 161A is assigned to well A of railcar 151A, the asset control manager 124 may send a control signal 290 to cause hostler 155 to retrieve and move unit 161A to a trackside location corresponding to well A of railcar 151A.

In some embodiments, control signals 290 generated by the asset control manager 124 may be used for manual control of the physical asset 135. For example, control signals 290 may be interpreted and acted upon by human operators. For example, control signal 290 may be displayed on a user interface (e.g., on user terminal 130), providing guidance to an operator on how to manually position or operate the physical asset 135 based on load plan 165.

FIG. 6 illustrates an example load plan 165 that may be generated by LPO System 160, according to particular embodiments. In some embodiments, load plan 165 includes a unit ID 605 that indicates an identification of a unit 161. In some embodiments, load plan 165 includes an assigned railcar 610 that indicates which railcar 151 to which the unit 605 is assigned. Track 615 is an identification of which track 156 the assigned railcar 610 is currently located. Well 620 indicates which well of the assigned railcar 610 the unit 605 is to be loaded. Top/Bottom 625 indicates which position (e.g., top or bottom) within well 620 the unit is to be loaded. Parking spot 630 indicates the current parking spots 170 of the unit 605. Driving distance 635 indicates how far hostler 155 must drive from sparking spot 630 to assigned well 620. Train ID 640 is an identification of the outbound train 148 of the assigned railcar 610. Train block ID 645 is an identification of the train block of the assigned railcar 610. Service level 650 is the assigned service level of unit 605 (e.g., P for priority, E for expedited, etc.). Goal date 655 is the date unit 605 should be delivered to its destination. Goal time 660 is the time that unit 605 should be delivered to its destination.

FIGS. 7A-7E illustrate various screens of a dashboard 167 that may be generated by the LPO System of FIG. 2, according to particular embodiments. FIG. 7A illustrates a screen 700A for displaying departed units 161 along with goals. In some embodiments, screen 700A includes a date input 710A that permits the user to select the actual depart date for the data displayed in screen 700. In some embodiments, screen 700A displays LPO units 715, non-LPO units 720, and a usage goal 725. In some embodiments, screen 700A displays LPO units 715, non-LPO units 720, and usage goal 725 for the overall system and for one or more hubs 140 (e.g., hubs 140A and 140B as illustrated in FIG. 7A).

FIG. 7B illustrates a screen 700B for displaying departed units 161 along with goals. In some embodiments, screen 700B includes date input 710A that permits the user to select the actual depart date for the data displayed in screen 700B. In some embodiments, screen 700B includes station filter 710B, a train ID filter 710C, a train symbol filter 710D, and a train block filter 710E that permits the user to filter the data displayed in screen 700B. In some embodiments, screen 700B includes a train detail 730 that lists LPO information about trains 148 (e.g., train ID, actual depart date, number of LPO units, number of non-LPO units, number of departed units, and LPO/Depart percentage). In some embodiments, screen 700B includes a user detail 735 that lists LPO information about user (e.g., WO assigned by, number of LPO units, number of departed units, and LPO/Depart percentage).

FIG. 7C illustrates a screen 700C for displaying ingate of units 161 versus train departure. In some embodiments, screen 700C plots the number of LPO units and the number of non-LPO units 720 on the y-axis and the train departure hours on the x-axis, as illustrated. In some embodiments, the x-axis of screen 700C may be divided into buckets (e.g., 4-hour buckets), as illustrated.

FIG. 7D illustrates a screen 700D for displaying details of units 161. The details of units 161 displayed in screen 700D may include a train ID, a unit ID, an indication of whether or not the unit is an LPO unit, an in-gate timestamp, a train depart timestamp, an in-gate to depart difference in hours, a user who submitted the LPO, a user who assigned the work order, an actual car ID, a planned car ID, an actual platform, and a planned platform. FIG. 7E illustrates a screen 700E for displaying LPO trends. In some embodiments, screen 700E displays a LPO count chart 740 that displays a LPO unit count (y-axis) graphed against actual depart dates (x-axis). In some embodiments, screen 700E displays a LPO count chart 745 that displays a LPO unit percentage (y-axis) graphed against actual depart dates (x-axis).

FIG. 8 is a chart illustrating a method 800 for optimizing load operations of a hub by automatically generating load plans, according to particular embodiments. In some embodiments, method 800 may be performed by LPO System 160 of hub optimization system 100. At step 810, method 800 accesses train data. In some embodiments, the train data is train data 225. In some embodiments, the train data indicates an inventory of units (e.g., units 161) currently in hub 140. In some embodiments, this step may be performed by data bifurcation module 220.

At step 820, method 800 accesses user preferences. In some embodiments, the user preferences are user preferences 227. In some embodiments, the user preferences indicate a particular outbound train 148 (or train block of the outbound train) that needs to be loaded with units. In some embodiments, the user preferences indicate a particular end of the production tracks 156 in which to start loading the outbound train.

At step 830, method 800 determines driving distances for candidate units to be loaded on the outbound train. In some embodiments, step 830 includes determining a subset of the inventory of units of step 810 according to the indicated outbound train of step 820. For example, if the train data of step 810 indicates that there are currently 2,000 specific units in inventory in the hub and step 820 indicates that a particular outbound train is to be loaded, step 830 may determine that only 200 of the units in inventory are eligible to be loaded on the particular outbound train (e.g., according to destination, priority, etc.). After determining the subset of eligible units, step 830 may determine driving distances from parking spots of each eligible unit to specific locations on the production track. In some embodiments, this may be performed by distance module 230.

At step 840, method 800 determines a track order using the determined driving distances of step 830. The track order may indicate an order of tracks 156 in which to assign units 161. In some embodiments, the track order is based on driving distances of step 830. In some embodiments, step 840 may be performed by track order module 240, as described herein.

At step 850, method 800 determines which units from the eligible units of step 830 in which to assign to the outbound train. In some embodiments, step 850 is performed by nearest unit approach module 260, as described herein.

At step 860, method 800 generates a load plan according to steps 810-850. In some embodiments, the load plan is load plan 165. In some embodiments, the load plan is generated by main optimization module 270. In some embodiments, the load plan is electronically sent for display on an electronic display of a user terminal 130. In some embodiments, the load plan is sent via an alert or a notification. After step 860, method 800 may end.

Particular embodiments may repeat one or more steps of the method of FIG. 8, where appropriate. Although this disclosure describes and illustrates particular steps of the method of FIG. 8 as occurring in a particular order, this disclosure contemplates any suitable steps of the method of FIG. 8 occurring in any suitable order. Moreover, although this disclosure describes and illustrates an example method including the particular steps of the method of FIG. 8, this disclosure contemplates any suitable method including any suitable steps, which may include all, some, or none of the steps of the method of FIG. 8, where appropriate. Furthermore, although this disclosure describes and illustrates particular components, devices, or systems carrying out particular steps of the method of FIG. 8, this disclosure contemplates any suitable combination of any suitable components, devices, or systems carrying out any suitable steps of the method of FIG. 8.

FIG. 9 illustrates an example computer system 900 that can be utilized to implement aspects of the various methods and systems presented herein, according to particular embodiments. In particular embodiments, one or more computer systems 900 perform one or more steps of one or more methods described or illustrated herein. In particular embodiments, one or more computer systems 900 provide functionality described or illustrated herein. In particular embodiments, software running on one or more computer systems 900 performs one or more steps of one or more methods described or illustrated herein or provides functionality described or illustrated herein. Particular embodiments include one or more portions of one or more computer systems 900. Herein, reference to a computer system may encompass a computing device, and vice versa, where appropriate. Moreover, reference to a computer system may encompass one or more computer systems, where appropriate.

This disclosure contemplates any suitable number of computer systems 900. This disclosure contemplates computer system 900 taking any suitable physical form. As example and not by way of limitation, computer system 900 may be an embedded computer system, a system-on-chip (SOC), a single-board computer system (SBC) (such as, for example, a computer-on-module (COM) or system-on-module (SOM)), a desktop computer system, a laptop or notebook computer system, an interactive kiosk, a mainframe, a mesh of computer systems, a mobile telephone, a personal digital assistant (PDA), a server, a tablet computer system, an augmented/virtual reality device, or a combination of two or more of these. Where appropriate, computer system 900 may include one or more computer systems 900; be unitary or distributed; span multiple locations; span multiple machines; span multiple data centers; or reside in a cloud, which may include one or more cloud components in one or more networks. Where appropriate, one or more computer systems 900 may perform without substantial spatial or temporal limitation one or more steps of one or more methods described or illustrated herein. As an example, and not by way of limitation, one or more computer systems 900 may perform in real time or in batch mode one or more steps of one or more methods described or illustrated herein. One or more computer systems 900 may perform at different times or at different locations one or more steps of one or more methods described or illustrated herein, where appropriate.

In particular embodiments, computer system 900 includes a processor 902, memory 904, storage 906, an input/output (I/O) interface 908, a communication interface 910, and a bus 912. Although this disclosure describes and illustrates a particular computer system having a particular number of particular components in a particular arrangement, this disclosure contemplates any suitable computer system having any suitable number of any suitable components in any suitable arrangement.

In particular embodiments, processor 902 includes hardware for executing instructions, such as those making up a computer program. As an example, and not by way of limitation, to execute instructions, processor 902 may retrieve (or fetch) the instructions from an internal register, an internal cache, memory 904, or storage 906; decode and execute them; and then write one or more results to an internal register, an internal cache, memory 904, or storage 906. In particular embodiments, processor 902 may include one or more internal caches for data, instructions, or addresses. This disclosure contemplates processor 902 including any suitable number of any suitable internal caches, where appropriate. As an example, and not by way of limitation, processor 902 may include one or more instruction caches, one or more data caches, and one or more translation lookaside buffers (TLBs). Instructions in the instruction caches may be copies of instructions in memory 904 or storage 906, and the instruction caches may speed up retrieval of those instructions by processor 902. Data in the data caches may be copies of data in memory 904 or storage 906 for instructions executing at processor 902 to operate on; the results of previous instructions executed at processor 902 for access by subsequent instructions executing at processor 902 or for writing to memory 904 or storage 906; or other suitable data. The data caches may speed up read or write operations by processor 902. The TLBs may speed up virtual-address translation for processor 902. In particular embodiments, processor 902 may include one or more internal registers for data, instructions, or addresses. This disclosure contemplates processor 902 including any suitable number of any suitable internal registers, where appropriate. Where appropriate, processor 902 may include one or more arithmetic logic units (ALUs); be a multi-core processor; or include one or more processors 902. Although this disclosure describes and illustrates a particular processor, this disclosure contemplates any suitable processor.

In particular embodiments, memory 904 includes main memory for storing instructions for processor 902 to execute or data for processor 902 to operate on. As an example, and not by way of limitation, computer system 900 may load instructions from storage 906 or another source (such as, for example, another computer system 900) to memory 904. Processor 902 may then load the instructions from memory 904 to an internal register or internal cache. To execute the instructions, processor 902 may retrieve the instructions from the internal register or internal cache and decode them. During or after execution of the instructions, processor 902 may write one or more results (which may be intermediate or final results) to the internal register or internal cache. Processor 902 may then write one or more of those results to memory 904. In particular embodiments, processor 902 executes only instructions in one or more internal registers or internal caches or in memory 904 (as opposed to storage 906 or elsewhere) and operates only on data in one or more internal registers or internal caches or in memory 904 (as opposed to storage 906 or elsewhere). One or more memory buses (which may each include an address bus and a data bus) may couple processor 902 to memory 904. Bus 912 may include one or more memory buses, as described below. In particular embodiments, one or more memory management units (MMUs) reside between processor 902 and memory 904 and facilitate accesses to memory 904 requested by processor 902. In particular embodiments, memory 904 includes random access memory (RAM). This RAM may be volatile memory, where appropriate. Where appropriate, this RAM may be dynamic RAM (DRAM) or static RAM (SRAM). Moreover, where appropriate, this RAM may be single-ported or multi-ported RAM. This disclosure contemplates any suitable RAM. Memory 904 may include one or more memories 904, where appropriate. Although this disclosure describes and illustrates particular memory, this disclosure contemplates any suitable memory.

In particular embodiments, storage 906 includes mass storage for data or instructions. As an example, and not by way of limitation, storage 906 may include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disc, a magneto-optical disc, magnetic tape, or a Universal Serial Bus (USB) drive or a combination of two or more of these. Storage 906 may include removable or non-removable (or fixed) media, where appropriate. Storage 906 may be internal or external to computer system 900, where appropriate. In particular embodiments, storage 906 is non-volatile, solid-state memory. In particular embodiments, storage 906 includes read-only memory (ROM). Where appropriate, this ROM may be mask-programmed ROM, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), electrically alterable ROM (EAROM), or flash memory or a combination of two or more of these. This disclosure contemplates mass storage 906 taking any suitable physical form. Storage 906 may include one or more storage control units facilitating communication between processor 902 and storage 906, where appropriate. Where appropriate, storage 906 may include one or more storages 906. Although this disclosure describes and illustrates particular storage, this disclosure contemplates any suitable storage.

In particular embodiments, I/O interface 908 includes hardware, software, or both, providing one or more interfaces for communication between computer system 900 and one or more I/O devices. Computer system 900 may include one or more of these I/O devices, where appropriate. One or more of these I/O devices may enable communication between a person and computer system 900. As an example, and not by way of limitation, an I/O device may include a keyboard, keypad, microphone, monitor, mouse, printer, scanner, speaker, still camera, stylus, tablet, touch screen, trackball, video camera, another suitable I/O device or a combination of two or more of these. An I/O device may include one or more sensors. This disclosure contemplates any suitable I/O devices and any suitable I/O interfaces 908 for them. Where appropriate, I/O interface 908 may include one or more device or software drivers enabling processor 902 to drive one or more of these I/O devices. I/O interface 908 may include one or more I/O interfaces 908, where appropriate. Although this disclosure describes and illustrates a particular I/O interface, this disclosure contemplates any suitable I/O interface.

In particular embodiments, communication interface 910 includes hardware, software, or both providing one or more interfaces for communication (such as, for example, packet-based communication) between computer system 900 and one or more other computer systems 900 or one or more networks. As an example, and not by way of limitation, communication interface 910 may include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI network. This disclosure contemplates any suitable network and any suitable communication interface 910 for it. As an example, and not by way of limitation, computer system 900 may communicate with an ad hoc network, a personal area network (PAN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), or one or more portions of the Internet or a combination of two or more of these. One or more portions of one or more of these networks may be wired or wireless. As an example, computer system 900 may communicate with a wireless PAN (WPAN) (such as, for example, a BLUETOOTH WPAN), a WI-FI network, a WI-MAX network, a cellular telephone network (such as, for example, a Global System for Mobile Communications (GSM) network, a Long-Term Evolution (LTE) network, or a 5G network), or other suitable wireless network or a combination of two or more of these. Computer system 900 may include any suitable communication interface 910 for any of these networks, where appropriate. Communication interface 910 may include one or more communication interfaces 910, where appropriate. Although this disclosure describes and illustrates a particular communication interface, this disclosure contemplates any suitable communication interface.

In particular embodiments, bus 912 includes hardware, software, or both coupling components of computer system 900 to each other. As an example and not by way of limitation, bus 912 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a front-side bus (FSB), a HYPERTRANSPORT (HT) interconnect, an Industry Standard Architecture (ISA) bus, an INFINIBAND interconnect, a low-pin-count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCIe) bus, a serial advanced technology attachment (SATA) bus, a Video Electronics Standards Association local (VLB) bus, or another suitable bus or a combination of two or more of these. Bus 912 may include one or more buses 912, where appropriate. Although this disclosure describes and illustrates a particular bus, this disclosure contemplates any suitable bus or interconnect.

Persons skilled in the art will readily understand that advantages and objectives described above would not be possible without the particular combination of computer hardware and other structural components and mechanisms assembled in this inventive system and described herein. Additionally, the algorithms, methods, and processes disclosed herein improve and transform any general-purpose computer or processor disclosed in this specification and drawings into a special purpose computer programmed to perform the disclosed algorithms, methods, and processes to achieve the aforementioned functionality, advantages, and objectives. It will be further understood that a variety of programming tools, known to persons skilled in the art, are available for generating and implementing the features and operations described in the foregoing. Moreover, the particular choice of programming tool(s) may be governed by the specific objectives and constraints placed on the implementation selected for realizing the concepts set forth herein and in the appended claims.

The description in this patent document should not be read as implying that any particular element, step, or function can be an essential or critical element that must be included in the claim scope. Also, none of the claims can be intended to invoke 35 U.S.C. § 112(f) with respect to any of the appended claims or claim elements unless the exact words “means for” or “step for” are explicitly used in the particular claim, followed by a participle phrase identifying a function. Use of terms such as (but not limited to) “mechanism,” “module,” “device,” “unit,” “component,” “element,” “member,” “apparatus,” “machine,” “system,” “processor,” “processing device,” or “controller” within a claim can be understood and intended to refer to structures known to those skilled in the relevant art, as further modified or enhanced by the features of the claims themselves, and can be not intended to invoke 35 U.S.C. § 112 (f). Even under the broadest reasonable interpretation, in light of this paragraph of this specification, the claims are not intended to invoke 35 U.S.C. § 112(f) absent the specific language described above.

The disclosure may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. For example, each of the new structures described herein, may be modified to suit particular local variations or requirements while retaining their basic configurations or structural relationships with each other or while performing the same or similar functions described herein. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive. Accordingly, the scope of the disclosure can be established by the appended claims. All changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. Further, the individual elements of the claims are not well-understood, routine, or conventional. Instead, the claims are directed to the unconventional inventive concept described in the specification.

Those of skill in the art would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure. Skilled artisans will also readily recognize that the order or combination of components, methods, or interactions that are described herein are merely examples and that the components, methods, or interactions of the various embodiments of the present disclosure may be combined or performed in ways other than those illustrated and described herein.

Functional blocks and modules in the included FIGURES may comprise processors, electronics devices, hardware devices, electronics components, logical circuits, memories, software codes, firmware codes, etc., or any combination thereof. Consistent with the foregoing, various illustrative logical blocks, modules, and circuits described in connection with the disclosure herein may be implemented or performed with a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

The steps of a method or algorithm described in connection with the disclosure herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal, base station, a sensor, or any other communication device. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.

In one or more exemplary designs, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. Computer-readable storage media may be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code means in the form of instructions or data structures and that can be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Also, a connection may be properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, or digital subscriber line (DSL), then the coaxial cable, fiber optic cable, twisted pair, or DSL, are included in the definition of medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

Although the present disclosure and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the disclosure as defined by the appended claims. Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods, and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the disclosure of the present disclosure, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized according to the present disclosure. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.