The mathematical model was coded using the OPL (Optimization Programming Language) and then solved using CPLEX Optimizer, wellknown mathematical programming solver. The generated solution, an achieved loading plan, the solver has been stored in an Access database. The Windows application RailLoad, implemented in Visual Basic, communicates with the Access database, visualizing the loading plan and enabling its user-friendly monitoring. All used software systems are available in the Microsoft Developer Network Academic Alliance.
In Serbia, closed H (Habis, Hbis, Hbbikks, Hbfkks, Hfkks) railcars are usually used to transport palletized goods. These railcars differ in their technical and, more importantly, operational characteristics, i.e., their carrying capacity and volume, usable floor length and width, mass, number of doors used for loading/unloading, maximum doorway width etc. It is therefore clear that a pallet loading scheme has to be different for each railcar type. The characteristics of different railcars and loading schemes for each of them should be stored in a separate database. In this research phase, this was done for Habis railcars.
Figure 3 shows the loading scheme of a Habis railcar, while the railcar’s characteristics are shown in
Figure 6. One can see that the railcar’s carrying capacity depends on the railway line category (A, B or C).
The implemented RailLoad software was tested on a large number of examples in which pallets (manufactured after 2011) were loaded into single or multiple Habis railcars. The selected examples are described in
Section 6.1 and
Section 6.2. The initial assumption was that any type of cargo could be placed in any position. Depending on the example, additional requirements that have to be met will be defined. Also, we will consider that box pallets are homogeneous bodies i.e., that their center of gravity is in the volume center of gravity. The goods are going to be transported by means of C railway line category, where the max allowed one-axle weight is 20t and the max allowed weight by meter is 6.4t/m, when the standard track width is 1.435m. In view of the fact that pallets can be loaded onto each other, they can be loaded into the Habis wagon in two levels, namely 14 pallets can be placed lengthways and three pallets width ways. The wagon’s total volume capacity, in the number of pallets, is 84. All examples are tested in a running environment with Intel Core i5-6400 CPU 3.30GHz and 8 GB RAM. Freight railcar load planning is not time critical, and most often it can be done even days before starting the loading itself. Our goal was not to find the optimal solution for one, but the “good enough” solution for more optimization criteria, and to eliminate incorrect loading and securing of goods. Having this in mind, CPLEX Optimizer CPU execution time was limited to 600 seconds [s] for all examples, but some simpler examples are resolved to optimality in a much shorter period.
6.1. Single Loading Examples
Example 1. Fifty pallets of each PTi, i = {1, …, 10} are available for loading. Only one type of goods should be loaded into wagon A.
The following cargo-related constraint that depends on the number of items due to be loaded PT
i, i = {1, …, 10} is now included in the model:
The following separation constraint allows the loading of only one PT into a railcar:
This is an example of the CLP classified as the IIPP. In the RailLoad application start window, the user selects option single railcar, railcar type: Habis, and activates the loading plan optimization software. The visualization of the achieved pallet arrangement generated by the RailLoad software is shown in
Figure 7. In view of the objective function and the mathematical model described in
Section 5.2, the loading of 50 PT7 pallets has been selected. We can see that, if a position on level I is empty, the corresponding position on level II has to be empty, too (e.g. 27 and 30, 63 and 66), while this, of course, is not the rule in the opposite case (e.g. positions 25 and 28, 26 and 29). The last position to be loaded is position 60. Thanks to the railcar loading monitoring panel, it is clear to the load organizer that there is a series of empty positions behind position 26.
Example 2. Fifty pallets of each Pti, i = {1, …, 10} are available for loading. They are to be loaded into wagon A.
The constraint (11) remains in force in this example as well. This problem is classified as a SLOPP: different PTs can be loaded into one wagon, so that the user selects the same options in the RailLoad application window as in the previous example. The software has generated a window with the problem solution, which will be left out here to save space. The solution details are outlined in
Table 3 and
Table 4. The wagon can be filled to its volume capacity with the adequate number of four different PTs (PT2, PT7, PT8 and PT9), with a carrying capacity utilization rate of 99.85%.
6.2. Multiple Loading Examples
Example 3. Twenty pallets of each PTi, i = {1, 2, 3} due to be loaded have to be loaded by all means and they all have to be loaded into the same wagon. Also, 30 pallets of each PTi, i = {4, …, 10} are due to be loaded as well. There are two wagons, A and B, into which they can be loaded.
We are faced here, and in the examples below, with a problem classified as the MILOPP: different PTs have to be loaded into identical wagons. It is evident that the basic mathematical model described in
Section 5.2 has to be modified taking into account the fact that the loading of items into two wagons is considered simultaneously. In this context, decision variables are as follows:
where
are 0–1 decision variables,
i = {1, …,
m},
j = {1, …,
n},
R∈{
A, B}.
Adapting other constraints to the loading of items into two wagons is not hard and will be left out here. Also, we have to introduce two additional constraints. Since items are to be loaded into two identical wagons (A and B), we can assume that the wagon into which all PT
i,
i = {1, 2, 3} will be loaded is wagon A. We therefore introduce the following connectivity constraint:
Also, the following cargo-related constraint depends on the number of pallets due to be loaded PT
i, i = {4, …, 10}:
The RailLoad software has generated the solution, the details of which are outlined in
Table 5, visualizing it in a user-friendly user interface. Each wagon can be filled to its volume capacity with 84 pallets, with the wagon A carrying capacity utilization rate amounting to 99.91% and the wagon B carrying capacity utilization rate amounting to 99.89%. Twenty pallets of each PT including PT1, PT2 and PT3 are in wagon A, as specified by the constraint (14). Also, 9 PT7, 2 PT8 and 13 PT9 pallets are in the same wagon. The loading included seven different PTs, five of which (PT1, PT2, PT3, PT7 and PT8) have been fully loaded.
Example 4. Forty pallets of PT1, have to be loaded into wagon A. Thirty pallets of each PTi, i = {2, …,10} are due to be loaded. They can be loaded into two wagons, A and B. In total, 50 PT5 and PT8 pallets have to be loaded.
The constraint that all 40 PT1 pallets must be placed in wagon A is the following positioning constraint:
The constraint (15) is valid in this example for ∀
i∈{2,
…, 10}. Also, we introduce a special constraint defining the total number of PT5 and PT8 pallets to be loaded:
The RailLoad software has generated the solution, the details of which are outlined in
Table 6, visualizing it in a user-friendly user interface. Each wagon can be filled to its volume capacity with 84 pallets, with the wagon A carrying capacity utilization rate amounting to 99.89% and the wagon B carrying capacity utilization rate amounting to 99.91%. All 40 PT1 pallets are in wagon A, as specified by the constraint (16). The requirement (17) that 50 PT5 and PT8 pallets precisely have to be loaded has been met as well (three PT5 pallets are in wagon A, while 24 PT5 and 23 PT8 pallets are in wagon B). Of the available 10 PTs, the loading included seven different PTs, three of which (PT1, PT2 and PT7) have been fully loaded.
Example 5. Thirty pallets of each PTi, i = {1, …, 10}, are available for loading. They are to be loaded into three railcars: A, B, and C. The PT6 and PT7 items must not be placed in the same wagon.
Considering that three railcars are to be loaded, with the modification of the mathematical model described in
Section 5.2 decision variables are now as follows:
where
are 0–1 decision variables,
i = {1, …,
m},
j={1, …,
n},
R∈{
A, B, C}.
The cargo-related constraint refers to the total number of pallets of each PT
i available for loading:
The separation constraint specifies that, if there is just one PT6 pallet in railcar A, B or C, no PT7 pallet can be placed in that railcar, and vice versa.
Once the user has selected the loading into multiple railcars (option: Multiple railcars) in the RailLoad application start window, and Railcar type for each (Habis) railcar, the loading plan optimization software is activated. It first displays the loading plan for the railcar with label A, but the user can also select the tab showing the loading plan for a railcar with a different label, e.g. label B as shown in
Figure 8.
Analyzing the loading plan for railcar B, we have concluded that the railcar can be filled to its volume capacity with 27 PT5 pallets, 29 PT6 pallets, 19 PT9 and 9 PT10 pallets. Also, the load organizer can clearly see the order in which a forklift truck should load the cargo: PT6, PT6, PT5, …, PT9, PT5, PT9.The railcar loading monitoring panel enables efficient monitoring of pallet loading. For example, if a forklift truck has just placed a PT5 pallet in position 3, it can be clearly seen that the next pallet to be placed in position 4 is also a PT5 pallet. The loading plan details for all three railcars are outlined in
Table 7 and
Table 8. PT6 pallets are in railcars B (29) and C (1), while all available PT7 pallets (30) are in railcar A, so that the constraint (19) has been fulfilled. Of the available 10 PTs, the loading included nine different PTs, seven of which (PT3, PT5, PT6, PT7, PT8, PT9 and PT10), i.e., all 30 available pallets, have been fully loaded.
Although there is a large number of papers dealing with CLP, we did not find academic publications that dealt specifically with loading to covered railcars, including real-world constraints tested on realistic benchmark data sets. We are sorry that we did not validate our solution in this way, however we strongly believe that the making of realistic benchmark data sets for this problem represents a challenge for future research. The software was validated by three experts for freight railcar loading by the following criteria:
user-friendliness
the speed of generating the solution
correctness of the proposed loading plan
clarity of graphical representation of the proposed loading plan
reliability, i.e., the possibility to completely rely on loading plan generated by the RailLoad software
clarity of load monitoring process.
Average rating by all criteria (in a range of 1 to 5, the higher the better) is 4.6.