Abstract:
A system for managing the transportation of crude oil by rail includes a user terminal having a display screen and a processing system coupled to the user terminal through a communications link. The processing system is operable to generate a user interface on the display screen of the user terminal receiving input information from a user, including information indicating a loading facility for loading a selected set of railcars and an unloading facility for unloading the selected set of railcars. The processing system is further operable to forecast an arrival time for the set of cars at the loading facility and an arrival time for the set of cars at the unloading facility and display the forecasted arrival times at the loading and unloading facilities on the display screen of the user terminal.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     The present application claims the benefit of U.S. Provisional Patent Application Ser. No. 61/886,818, filed Oct. 4, 2013. 
    
    
     FIELD OF INVENTION 
     The present invention relates in general to railroad management techniques, and in particular to systems and methods for managing railcar usage. 
     BACKGROUND OF INVENTION 
     Railroad customers, particularly those having to ship large amounts of product on a relatively tight time schedule, have a critical need for reliable rail plans. These rail plans should provide the railroad customer, as well as the servicing railroad, with reliable information about the resources available at a given time and place (e.g., the sets of cars available to service a particular route), accurate forecasts of train arrival and departure times at product loading and unloading facilities, and potential bottlenecks within the product transportation system (e.g., Facility queuing and dwell times, among other things. 
     Current rail planning systems, however, are subject to a number of problems. Typically, each individual customer uses multiple unlinked spreadsheets and manual calculations of the various parameters to generate rail plans. Moreover, these plans are normally not based on real set cycle data nor account for actual train movements. As a result, not only have the railroad customers struggled to generate reliable rail plans, but the servicing railroad is faced with the resulting burden of reconciling and proofreading spreadsheets from different customers in addition to the normal burden of managing the trains themselves. 
     SUMMARY OF INVENTION 
     The principles of the present invention are embodied in computer-based systems and methods, which allow a railroad company and its customers to plan, schedule, and managing the transport of crude oil by rail. One particular embodiment is a combination hardware-software system for managing the transportation of crude oil by rail, which includes a user terminal having a display screen and a processing system coupled to the user terminal through a communications link. The processing system generates a user interface on the display screen of the user terminal for receiving input information from a user, including information indicating a loading facility for loading a selected set of railcars and an unloading facility for unloading the selected set of railcars. The processing system is further operable to forecast an arrival time for the set of cars at the loading facility and an arrival time for the set of cars at the unloading facility and display the forecasted arrival times at the loading and unloading facilities on the display screen of the user terminal. 
     In addition, various embodiments of the present principles also provide for the generation of graphs on a user terminal, which allow the user to quickly discern the forecasted operations of shipments on a particular lane, the forecasted operations of a particular set of cars, and tank levels at the loading and unloading facilities. Furthermore, a preferred set of algorithms, suitable for execution in software on the disclosed hardware-software system, is disclosed for forecasting arrival times at loading and unloading facilities, for identifying a best set option for providing a shipment to a particular facility on a particular date, as well as for determining the necessary number of shipments or sets required to meet a crude oil throughput goal. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
       For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which: 
         FIG. 1  is a high level functional block diagram illustrating a representative computer network operating environment in which the principles of the present invention can advantageously be applied; 
         FIG. 2  is a diagram illustrating a representative main display screen (page) presenting information generated by the server and displayed on a corresponding one of the end user terminals in the system of  FIG. 1 ; 
         FIG. 3  is a diagram illustrating a representative plan management screen (page) presenting information generated by the server and displayed on a corresponding one of the end user terminals in the system of  FIG. 1 ; 
         FIG. 4  is a diagram illustrating a representative or facilities parameters screen (page) presenting information generated by the server and displayed on a corresponding one of the end user terminals in the system of  FIG. 1 ; 
         FIG. 5A  is a more detailed diagram of the graphical portion of the main display screen of  FIG. 2  showing a representative projected shipping operations, including queuing alerts and potential conflicts; 
         FIG. 5B  is a flow diagram illustrating a representative procedure for estimating a time of arrival for an immediate next arrival at selected facility based on a preceding events for a set; 
         FIG. 5C  is a flow diagram illustrating a representative procedure for estimating a transit time from an origin to a destination; 
         FIG. 5D  is a flow diagram illustrating a representative procedure for estimating a transit time from the destination back to the origin; 
         FIG. 5E  is a flow diagram illustrating a representative procedure for estimating queuing and dwell time at a loading/unloading facility; 
         FIG. 5F  is a diagram illustrating the relationship between car sets during queuing and dwelling at a loading/unloading facility; 
         FIG. 5G  is a flow diagram illustrating a representative procedure for estimating the number of shipments required to meet a throughput goal; 
         FIG. 5H  is a flow diagram illustrating a representative procedure for estimating the number of car sets required to meet a throughput goal; 
         FIG. 6A  is a diagram illustrating a representative set management display screen (page) presenting information generated by the server and displayed on a corresponding one of the end user terminals in the system of  FIG. 1 ; 
         FIG. 6B  is a diagram showing a particular example of a preferred procedure for calculating the best set option for delivering a particular shipment to a specific destination on a specific date using the screen shown in  FIG. 6A ; 
         FIG. 6C  is a more detailed diagram of the graphical portion of the main display screen of  FIG. 2  depicting representative operations of a selected set; 
         FIG. 6D  is a flow chart depicting a preferred procedure for determining the sets available to a particular customer; 
         FIG. 7A  is a more detailed diagram of the graphical portion of the main display screen of  FIG. 2  depicting an exemplary prediction of the tank level at a selected facility based on the forecasted train schedules calculated using the procedures of  FIGS. 7B and 7C ; 
         FIG. 7B  is a flow chart illustrating a preferred procedure for estimating the hourly tank level at a loading facility; and 
         FIG. 7C  is a flow chart illustrating a preferred procedure of estimating the hourly tank level at an unloading facility. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     The principles of the present invention and their advantages are best understood by referring to the illustrated embodiment depicted in  FIGS. 1-7  of the drawings, in which like numbers designate like parts. These principles will be described using a system for planning, scheduling, and managing the transport of crude oil by rail, although it should be recognized that they are generally applicable to the transport by rail of other types of products, as well. 
       FIG. 1  is a high-level conceptual block diagram of an exemplary network-based computer system  100  suitable for describing a typical application of the principles of the present invention. In the illustrated embodiment, system  100  is based on a host data processing and control system (server)  101  and a global network  102 , such as the Internet. Global network  102  could also be a private, organizational, or governmental computer-based network known in the art, such as a wide area network (WAN) or local area network (LAN). The interconnections between the operational blocks shown in system  100  shown in  FIG. 1  can be implemented by hardwired connections, wireless connections, or a combination of the two. 
     Generally, the application of the principles of the present invention is independent of the high-level architecture and high-level hardware-software implementation of system  100 . System  100  allows a user (e.g., a railroad customer or railroad) to monitor and manage the shipment of crude oil by rail using an end user terminal  103 , railroad host server  101  and associated database  105 , communications interconnections  104 , and network  102 . End user terminals  103 , may be, for example, a desk top computer, laptop computer, tablet, mobile phone, or similar conventional computing-communications device, which supports standard network interfacing through browsers or applications. In the typical operating environment, system  100  will have multiple users, including those employed by the railroad and those employed by the customer, and a corresponding number of end user terminals  103 , although only three end user terminals  103 , and a corresponding number of communications interconnections  104 , are shown in  FIG. 1  for reference. 
     The subsystems of system  100 , including railroad host server  101 , database  105 , and communications interconnections  104  are preferably based on hardware and software systems known in the art, including computers, servers, processors, displays, and communications systems. Depending on the particular configuration of system  100  being employed, the base hardware and software can be, in whole or in part, localized (e.g., at a geographically centralized data center) or distributed (e.g., at multiple geographically-diverse processing nodes). 
       FIG. 2  illustrates a representative main screen displayed on a given user terminal  103 , according to the principles of the present invention. Generally, main screen  200  allows crude oil shipments to be assigned to sets of railcars allocated to a particular customer and then manages under dynamic circumstances. More particularly, main screen  200  includes a user interface section  201 , which allows the user to edit the origin and destination points for shipments and review the resulting forecasted arrival times. User interface section, which is generated by software running on railroad host server  101  and the corresponding end user terminal  103 , provided for the input and output of information to system  100 . A graphical section  202  provides a graphical display allowing the user to graphically view operations based on shipment, railcar set, or facility. In the illustrated embodiment, the graphs shown in graphical section  202  are generated using commercially available software, such as Highcharts, running on either railroad host server  101 , the corresponding user terminal  103 , or both. 
     For purposes of the present discussion, a “shipment” is the delivery of crude to a destination, a “set” is a set of railcars making the shipment, and a “lane” is a specific combination of an origin (loading facility) and a destination (unloading facility). “Queuing time” is the time a set spends waiting to load and unload at a facility.” “Dwell time” is the total time spent at a facility, which includes queuing time and loading/unloading time. “Online time” is the time spent on the railroad providing services through system  100 . “Offline time” is the time spent on another railroad (i.e., a “foreign carrier”). 
     In the illustrated embodiment, each shipment is identified by a set identifier  203 , set owner  204 , and the number of cars in the set  205 . A window  206  allows the user to edit the facility at which the set will be loaded (e.g., the origin). In response, system  100  generates and displays a forecast arrival date and time  207  of the set at the loading facility. Similarly, a window  208  allows the user to edit facility at which the set will be unloaded (e.g., the destination), after which system  100  generates and displays a forecast arrival date and time  209  of the set at the unloading facilities. The data on user interface section  201  may be sorted by forecast loading arrival date and time  206  or forecast unloading arrival date and time  209 . (In the example shown in  FIG. 2 , the displayed information is sorted by unloading arrival date and time  209 ). 
     Graphical section  202  is associated with a tab  211  for graphically displaying operational data by shipment, a tab  212  for graphically displaying operational data by set, and a tab  213  for graphically displaying operational data by facility. In  FIG. 2 , the user has selected tab  211  and the operational data is being displayed by set, in this case, the set with the set identifier U2013_0004. Graphical section  202  is described in further detail below. 
       FIG. 3  depicts a representative plan management screen  300  generated by software running on system  100  (e.g. railroad host processor  101 , the corresponding user terminal  103 , or both) and displayed on a given end user terminal  103 . Plan management screen  300  generally allows a user to create and erase planning scenarios, export created scenarios to an MS Excel file, or summarize shipments (e.g. by barrels per day) within a planning horizon. Scenarios can be either active scenarios, which are implemented, or “what-if” scenarios, which allows the user to forecast operations in response to varying parameters and conditions. 
     Plan management screen  300  includes a graphical button  301  for activating a created plan and a graphical button  302  for creating a new plan. Two plans are shown in  FIG. 3 , an active plan  303  and a “What if” plan  304 . Each plan is characterized by parameters including a plan identifier  306 , creation date  307 , a last modification date  308 , a forecast number of barrels per day (BBLS/day)  309 , a forecast number of actual sets used  310 , a forecast number of virtual sets  311 , a forecast number of shipments queued  312 , and the forecast total queuing time  313 . A tool for forecasting the number of sets needed for a given throughput goal is discussed below in connection with  FIG. 5G , while a tool for forecasting the number of shipments needed for a throughput goal is discussed below in connection with  FIG. 5H .  FIG. 6D  illustrates a tool for determining the number of sets available to a particular customer, also discussed further below. 
     A representative facilities parameters screen  400  is shown in  FIG. 4 . Generally, this screen allows the user to edit facility parameters, such as the number of loading racks available, add or subtract the number of days per cycle time used for planning, and change the storage tank parameters (e.g., for calculating crude inflow). 
     As shown in  FIG. 4 , facilities parameters screen  400  may be used to vary the parameters or conditions at both loading facilities  401  and unloading facilities  402 . These variables include dwell time  404 , number of loading racks  405 , barrels per car  406 , and maximum cars per train  407 . In addition, the user can also enter any blackout parameters  403  for those loading an unloading facilities. Blackouts can be characterized by facility  408 , starting date  409 , starting time  410 , ending date  411 , and ending time  412 . 
       FIG. 5A  is a detailed view of shipment operations graph pulled up in graphical section  202  of main screen  200  of  FIG. 2  using shipments tab  211 . In  FIG. 5A , ten (10) shipments  501  between Stanley, N. Dak. and St James, La., are shown as an example. (A graph bar for one unidentified shipment is shown as a reference for discerning the overlap between graph bars in  FIG. 5A ). 
     Each shipment is graphically shown as a bar graph including the loading time at the origin  502 , the transit time from the origin to the destination  503 , the unloading time at the destination  504 , and the return transit time from the destination to the origin  505 . In the event a shipment is queued for loading at the origin, the queue time  505  is also graphically depicted. Advantageously, shipment tab  211  allows a user to quickly discern the forecasted operations on a particular lane, including potential bottlenecks (e.g., queuing times). 
     A preferred Procedure  510  for estimating the time of arrival for the immediate next arrival at a facility (either loading or unloading) based on a set of preceding events reported from the train and entered into system  100  is shown in  FIG. 5B . Procedure  510 , which is preferably executed in software running on railroad host server  101  and the given end user terminal  103 , advantageously provides the higher degree of granularity needed for forecasting the immediate next arrival at a facility, in contrast to Procedures  520  and  530  discussed below, which are more generally applicable for forecasting arrival times at the loading and unloading facilities. Preferably, Procedures  520  and  530  are used for forecasting arrivals at a facility other than the immediate next arrival, which are generally more tolerant to a lesser degree of granularity. With regards to Procedures  510 ,  520 ,  530 , it is being assumed that a foreign carrier is transferring a set into or out of the facility, although this is not always necessary for practicing these procedures, 
     If the last reported event was the set placed for loading or unloading at the starting facility at Decision Block  511 , the estimated time of arrival at the facility is calculated at Block  512  as:
 
Estimated Time of Arrival at Facility ( TA )=Time Placed for Loading ( APPL )/Unloading ( APPU ) to Estimated Time Loaded Release ( RIRL )/Empty Release ( RIRE ) at Starting Facility+Estimated Time of Loaded/Empty Release to Estimated Time of Departure ( TD ) from Starting Facility+Estimated Time of Departure from Starting Facility to Estimated Time Received from Interchange ( RR )+Estimated Time Received from Interchange to Estimated Time to Ending Facility
 
     If the last event taking place was the set released (loaded or unloaded) at Decision Block  513 , then the estimated time of arrival at the destination is calculated at Block  514  as:
 
Estimated Time of Arrival at Facility=Time of Loaded/Empty Release at Starting Facility to Estimated Time of Departure from Starting Facility+Estimated Time of Departure from Starting Facility to Estimated Time Received from Interchange+Estimated Time Received from Interchange to Estimated Time to Ending Facility
 
     If the last event was departure, at Decision Block  515 , then the estimated time of arrival at the destination is calculated at Block  516  as:
 
Estimated Time of Arrival at Ending Facility=Time of Departure from Starting Facility to Estimated Time Delivered for Interchange+Estimated Time Received from Interchange to Estimated Time to Ending Facility
 
     Finally, if at Decision Block  515  the last event was received from interchange (i.e., the last event was not departure), then at Block  517 , then the estimated time of arrival at the destination is calculated as:
 
Estimated Time of Arrival at Ending Facility=Time Received from Interchange to Estimated Time to Ending Facility
 
     A preferred procedure  520  for calculating the average transit time to a particular destination is shown in  FIG. 5C . Procedure  520  is preferably implemented in software executed on railroad host server  101  and/or the corresponding user terminal  103 . At Decision Block  521  a determination is made as to whether at least five data points representing transit times for the given lane over a given time period are available. If these five data points are not available, then at Block  522  the average transit time to the particular destination is calculated as the average time to that destination from all origins within the geographical region. 
     On the other hand, if five data points representing transit times for the given lane are available, then at Block  523 , the average transit time is calculated as the historical average transit time:
 
Historical Loaded Average Transit Time to Destination=Average Time From Release by the Customer at Loading Facility to Departure from Loading Facility ( ORIG AVE)+Average Time from Train Departure from Loading Facility to Train Arrival at Unloading Facility or Train Arrival at Destination ( TDTA AVG)+Average Time from Arrival at Unloading Facility to Spot at Unloading Facility or Average Time Arrival at Railroad 1 Destination to Interchange Delivery to Foreign Carrier ( DEST AVG)+Average Time from Interchange Delivery of Train to Foreign Carrier to Spot Arrival at Unloading Facility (Average Unloading Dwell Time− DDAP AVG)+Average Offline Time from Arrival to Release at Unloading Facility (Spent of Foreign Carrier) ( OAPRI AVG,  EAPRI AVG)+
 
     A preferred Procedure  530  for determining the average transit time to the origin is shown in  FIG. 5D . Procedure  530  is preferably implemented in software executed on railroad host server  101  and/or the corresponding user terminal  103 . At Decision Block  531 , a determination is made as to whether at least five data points representing transit times for the given lane over a given time period are available. If these five data points are not available, then at Block  532  the average transit time to the particular origin is calculated as the average time to that origin from all destinations within the geographical region. 
     Otherwise, if five data points representing transit times for the given lane are available, then at Block  533 , the average transit time is calculated as the historical average transit time:
 
Historical Empty Average Transit Time to Origin=Average Time from Release from Unloading Facility to Return from Foreign Carrier ( RIRR AVG)+Average Time From Release by the Customer at Unloading Facility to Departure from Unloading Facility or Average Time From Foreign Carrier Interchange to Railroad 1 Departure ( ORIG AVE)+Average Time from Train Departure from Unloading Facility to Spot Train Arrival at Loading Facility ( TDTA AVG)+Offline Time from Release to Foreign Carrier to Departure from Unloading Facility (Offline Release to Depart Time) ( ORITD AVG)
 
     In some embodiments, the user may adjust the average transit time (either loaded or empty) from the historical average time to account for known delays or conflicts in a lane or to execute a “what if” scenario. Transit time adjustments are made using a window in a manner similar to the parameter adjustments made using the parameter display of  FIG. 4 . The user is limited to increasing the transit time above the historical average and cannot decrease the transit time to below the historical average. 
       FIG. 5E  illustrates a preferred Procedure  540  for estimating queuing and dwell time at a facility. In the preferred embodiment, Procedure  540  is implemented in software executed on railroad host server  101  and/or the corresponding user terminal  103 . At Decision Block  541 , a determination is made as to whether the customer owns any facilities. If so, then the queuing and dwell times are calculated based on the first-in, first-out status of the trains (Block  542 ). Otherwise, at Block  543 , the dwell time is calculated as the average dwell at the facility for all active trains and the queuing time is calculated as the average queue time at the facility for all active trains. Advantageously, the queuing time estimate allows the owner of a facility to observe the order of trains arriving at their facility, a feature which is typically not required for non-facility owners. 
       FIG. 5F  illustrates an example of the operation at Block  543  for a customer does not own or operate the facility but does have five sets subscribed to that facility. 
     Procedure  550 , shown in  FIG. 5G , is a preferred method for estimating the number of shipments required to meet a throughput goal. Procedure  550  is preferably implemented in software executed on railroad host server  101  and/or the corresponding user terminal  103 . At Block  551 , the crude throughput goal, number of cars per train, and barrels per car are input into the model. The number of barrels per train is calculated at Block  552  as the product of the number of cars per train and the number of barrels per car. The number of shipments required to meet the throughput goal is calculated at Block  553  by dividing the crude throughput goal, in barrels, by the number of barrels per train. 
     A Procedure  560  for estimating the number of sets required to meet a throughput goal is shown in  FIG. 5H . Preferably, Procedure  520  of  FIG. 5C  (i.e., determining the average transit time to the destination), Procedure  530  of  FIG. 5D  (i.e., determining the average transit time to the origin), and Procedure  540  of  FIG. 5E  (i.e., estimating the average queuing and dwell time at a facility) are used to implement Procedure  560 , although this is not a strict requirement. Procedure  560  is also preferably implemented in software executed on railroad host server  101  and/or the corresponding user terminal  103 . 
     At Block  561 , the number barrels per car, the crude throughput goal, the number of days in the planning horizon, and number of cars per train are input into the model. The crude flow per day is calculated at Block  562  as:
 
Crude Flow Per Day (Barrels)=Crude throughput GOAL (Barrels)÷Number of Days in Planning Horizon
 
     The average total cycle time is then calculated at Block  563  as:
 
Average Total Cycle Time=Average Time at Origin+Average Transit Time To Destination+Average Time at Destination+Average Transit Time to Origin
 
     At Block  564 , the number of barrels per train is calculated as:
 
Barrels per Train=Number of Cars Per Train×Number of Barrels Per Car
 
     The number of sets (trains) required to meet the throughput goal is calculated at Block  565  as:
 
Number of Sets to Meet Throughput Goal=(Average Cycle Time×Crude Flow Per Day)÷Number of Barrels Per Set
 
       FIGS. 6A and 6B  illustrate the use of main screen  200  to identify the sets that can be made available to a customer to provide a shipment to a given facility on a given date. Generally, the user brings up a search pane  601  using a graphical button or similar interface, as shown in  FIG. 6A . In the illustrated embodiment, the user uses a window  602  to select a facility and a window  603  to select a target date. System  100  then provides options (“theoretical lines”) for achieving the desired shipment by editing the current scheduling of one or more sets. The process shown in  FIGS. 6A and 6B  are preferably implemented in software executed on railroad host server  101  and/or the corresponding user terminal  103 . 
       FIG. 6B  illustrates a particular example where the customer wishes to deliver a shipment of crude to Hayti, Mo. with an unloading arrival of April 21. For each of the scheduled shipments shown in the user interface portion  201  of main screen  200 , system  100  calculates an estimated time (ETA) of arrival at Hayti based on the ETA to each currently scheduled loading facility  207  and the cycle time to Hayti (e.g., a theoretical lane). For example, set 2012_99 is scheduled to arrive at Eland, N. Dak. on April 4 for loading. After adding the cycle time to Hayti, Mo., to the loading date of April 4 system  100  calculates an ETA of April 18 for the theoretical lane from Eland to Hayti, as shown in option #1 in conceptual box  641  of  FIG. 6B  (box  641  is preferably not part of the actual display). 
     System  100  highlights the best theoretical lane, which provides an arrival date that is either on the target date or is the closest arrival date before the target date. In this example, set 013_007 on entry line  640  from Manitou to Hayti, provides the closest ETA of April 20. The user can then decide to change the destination of set 2013_007 from St. James, La., to Hayti, Mo. to achieve the desired goal. 
       FIG. 6C  illustrates a typical graphical representation of the operation of a set under sets tab  211  of graphical section  202  of main screen  200  of  FIG. 2 . In the illustrated embodiment, shipments are grouped by set I.D.  611 , in this case, set U2013_0004. Each shipment is represented in time by a bar  612 , which shows the loading time  613 , the transit time to the destination  614 , the unloading time  615 , and the return transit time to the origin  616 . By hovering over a particular shipment, a screen bubble  617  appears, which provides more particular details about the shipment, in this example, the empty time for the set. 
     A preferred Procedure  620 , which is preferably implemented in software running on railroad host processor  101  and/or the corresponding user terminal  103 , for determining those sets available to a particular customer is shown in  FIG. 6D . At Decision Block  621 , a determination is made as to whether the customer owns any facilities. If so, then at Block  621  the sets available, by set I.D. are:
 
Sets Available to Customer=All Sets Loaded or Unloaded At Customer Facility In Most Recent Cycle+Any Sets Assigned to Customer in Set ID Database
 
     If the customer does not own any facilities at Decision Block  621 , then the sets available to the customer are only those sets assigned to the customer in the set I.D. database (Block  623 ). Advantageously, the owner of a facility, which may have multiple railroads servicing a facility, can see all sets going into and out of a facility, whether or not the facility name is on the waybill. 
       FIG. 7A  is a graphical representation of the predicted tank level at a particular customer facility, as displayed under facilities tab  212  for graphics section  202  of main screen  200 .  FIGS. 7B and 7C  illustrate preferred procedures for generating the display shown in  FIG. 7A  based on forecasted train schedules. 
     Specifically, Procedure  700  shown in  FIG. 7A  calculates the estimated hourly tank level at a loading facility and is preferably implemented in software running on railroad host processor  101  and/or the corresponding user terminal  103 . At Block  701 , the inputs to the model include the hourly crude inflow by truck, hourly crude inflow by pipe, and the current tank level. The model estimates the hourly outflow by rail based on the forecasted train (set) cycles. The hourly crude inflow is then calculated at Block  702  as:
 
Hourly Crude Inflow=Hourly Crude Inflow by Truck+Hourly Crude Inflow by Pipe
 
     The hourly tank level at the loading facility is then calculated at Block  703 :
 
Hourly Tank Level at Loading Facility=(Currently Tank Level+Hourly Crude Inflow)−Hourly Crude Outflow by Rail
 
       FIG. 7B  illustrates a preferred Procedure  710  for estimating the hourly tank level at an unloading facility. Procedure  700  is also preferably implemented in software running on railroad host processor  101  and/or the corresponding user terminal  103  At Block  711 , the inputs to the model include the hourly crude outflow by truck, hourly crude outflow by pipe, and the current tank level. The model estimates the hourly outflow by rail based on the forecasted train (set) cycles. The hourly crude inflow is then calculated at Block  712  as:
 
Hourly Crude Outflow=Hourly Crude Outflow by Truck+Hourly Crude Outflow by Pipe
 
The hourly tank level at the unloading facility is then calculated at Block  713 :
 
Hourly Tank Level at Unloading Facility=(Current Tank Level+Crude Outflow by Rail)−Hourly Crude Outflow by Rail
 
     Although the invention has been described with reference to specific embodiments, these descriptions are not meant to be construed in a limiting sense. Various modifications of the disclosed embodiments, as well as alternative embodiments of the invention, will become apparent to persons skilled in the art upon reference to the description of the invention. It should be appreciated by those skilled in the art that the conception and the specific embodiment disclosed might be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. 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 invention as set forth in the appended claims. 
     It is therefore contemplated that the claims will cover any such modifications or embodiments that fall within the true scope of the invention.