Month: March 2020

After a lot of thought and a bunch of playing around with the code and running many tests, I have come to the conclusion that trying to have a prioritized order to the car attributes will not work. The thought was that if we could figure out the right order from most important to least, then we could start to relax the matching specifications by first ignoring the least important one, and so on with increasing importance. This would help to “force” a close-enough match during restaging.

The main problem with this idea is that there is really no intrinsic relative importance to these attributes, so that we could ignore the attributes in a fixed sequence of increasing order of importance. Such an ordering does not exist in general, because what may be safely ignored in one situation might not be the same in another. For example, is the car owner more or less important than its length? I think the correct answer is “it depends…” We may have roles that must have CPR cars because there is a contract to supply them but they don’t care about the length, and we might have other roles that must have a certain car length to fit at a loading dock but don’t care who the owner is. Neither is always more important than the other. A better way is needed to indicate what is optional and what is not.

Here is what I came up with, at least for now. Taking car length as an example, currently the program will accept an input of blank or “*” to indicate “don’t care”, or a list of one or more specific items to indicate that any one of them is acceptable. For example, a role with a length specification of “*” means that any length car is acceptable. A specification of “40|50|60” means that a car length of 40, or 50, or 60 feet is acceptable, but nothing else.

I am proposing to extend this approach and allow for something like 40|50|*, which would mean either 40 or 50 feet to start, but if there is no match, then the length can be relaxed to “Any” for a subsequent attempt. Exactly how this would apply when there are multiple attributes that include an “*” is not clear to me yet, but I’m sure something will emerge. The issue is that if a role has say three attributes that all can be relaxed, which one (or more) do you try first? How many attempts do you try? What order do you relax them in? As a start to implement the basic idea of being able to make some attributes optional, I will just have it be all or nothing. The first pass should match exactly or not, and a second pass will simply ignore all of the “relaxable” attributes.  Maybe we should call them “Optional” attributes if they include an “*”?

The end result is that each role can include some specifications that are not optional and must be matched (they don’t include an “*”), and some that are optional and may be ignored in order to keep the cars rolling. I think this should provide enough flexibility, at least for now.

My process to restage cars in staging by finding a role for each car relies on being able to find at least one suitable role for each car that is restaged. If no role can be found the car must be removed temporarily to storage. This approach works well when there are enough suitable roles to select from for a given car, but it breaks down when there are not. Too many cars may end up in storage when the entire point of the exercise is to run trains! A solution to keep cars moving is to substitute roles that are not a perfect match and carry on. Colin mentioned that he and Gary often have to do just that when using their traditional paper car card and waybill system. I’d like to capture some of the ideas behind how this “forced” matching is worked out and implement it in the program.

There are obvious things we can do in some cases. For example, if the particular car to be restaged has 6 foot doors but there are no roles asking for a 6 foot door, only 8 foot, then we may decide to send the car anyway, even though its door is narrower than what is requested and a real shipper would be angry because their forklift truck would not fit. The basic notion here is that there may be some parts of the car spec that can get ignored to help find a match, without causing too much grief. In this case we ignored the door attribute because it really doesn’t matter, nothing will actually be loaded. Maybe there is an order of things that we can ignore in the hope of finding a match so that the car does not have to get pulled off into storage. For example, if we don’t find a match to start, first ignore the door spec, if still no match, then ignore the car class, and so on until we run out of things we are willing to compromise on and the car has to be moved to storage. I suspect that people go through something like this in their minds when selecting paper waybills. I’d like to try to capture that in some simple rules that I can implement in the program.

Ok, so now we have a bunch of attributes that describe a car, but how do we use this when restaging cars? The things that will make use of all of this car attribute stuff are called “Roles”. A Role includes basic shipment information, but it also contains the entire life-cycle of a car from staging, on to the layout, and eventually back to staging. Some of the phases of that life-cycle have the car being moved empty for supply or return, so there really is no shipment for those parts, hence the new name “Role”. Roles now replace the earlier primitive shipment model that made too many assumptions and caused a lot of grief.

Every car in staging that is about to return on to the layout requires a role that governs all of the places that car will go. For every car being restaged, the program searches through all of the available roles to find those that are suitable for that car by considering all of its attributes. Roles contain a Car Specification that gets tested for a match to the car. A very simple example role might say that it wants a “Boxcar:40” and is silent on the other attributes, so they are considered as “don’t cares”, and only the Car Type and Nominal Length of the Car will be considered. In this case, every 40 foot box car waiting to be restaged would be a match.

This is all part of the process that we go through manually with paper Car Cards and Waybill systems during restaging, I just want to capture the essence of the process and automate it.

Roles usually specify a car type and a couple of the other attributes, but the process of matching cars to roles can get quite complex when we start to think about more subtle issues. What if a shipper can accept cars of different lengths, but not just any length, say 40 or 50 foot, but no longer. And how do we handle roles that apply only to specific individual cars and no others, even if they share the same attributes? A good example of this would be captive service between two industries. And of course there is the owner railroad, and reporting marks to consider. The combinations can grow to be quite complex in order to handle all of these special cases, but we still want the system to be easy to define for the much more common simple cases without becoming so complex that it is hard to understand.

This sounds like it is getting very complicated to set up the data, but please remember that all of these fields can be left blank or filled with just an asterisk (*) and they will not be considered during selection. Only a few of the fields will be routinely used, such as Car Type and Nominal Length. 

My solution is to use a series of “Specifications” that each contain a description of which car attributes are “acceptable” to the Role for that piece. The combination of all of these specs is referred to as the Car Specification. So, what is a specification? In simple terms it holds zero or more car attributes that can be matched to a specific car to see if they match or not. The whole notion of a “match” is non-trivial, as we must handle multiple acceptable values, an empty list that signifies that we don’t care about that particular car attribute, and cars that have empty attributes.

Some examples should help makes this clearer. Let’s consider a car’s nominal length. If an industry can accept only 40 foot cars due to loading dock spacing, that would be specified simply as “40”. If it can handle 40 or 50, but no other lengths, it would be specified as “40|50”, where the “|” (vertical bar) signifies “either”. A specification list can hold as many alternatives as needed. In this case, when the role is being considered for a particular car being restaged, it will be included as a possible candidate for any car with a length of 40 or 50 feet. Other actions will affect which role finally gets selected, but it first must be a candidate role that matches the car. The overall selection process does this matching for all non-empty specifications.

On the other hand, if we don’t care about the length of the car, for say a team track, then the specification becomes a simple asterisk, “*”, meaning “don’t care”, and the role will match any car length.

A more complete example would be for a Boxcar, 40 or 50 foot, Clean or High class, with 6 or 8 foot Doors, but we don’t care about a Subtype, or a Capacity. The car specification for this would be:

Box:40|50:*:Clean|High:D6|D8:*

The complete specification will also include more don’t cares for the initials, number, and owner railroad, but these have not been added in yet.

I started to think more about the car attributes and which ones are really necessary. I had said that we need the Car Type and Nominal Length, but not always the other four attributes. Now I am thinking that they are all optional. Stay with me for a moment, and it may make sense. Ok, we do need the Car ID, namely the Road and Number, otherwise we can’t find the car to move, and we need the actual length to make sure there is space for it. But as for the other things, they are only used to select suitable shipments for the cars when they get restaged. It would work even if we had all six attributes blank, meaning “don’t care”, or “unknown” for everything. That means that such a car could be given any role, as there is nothing to match on. While this sounds silly, it is a good way to get a new system started by generating lots of car movements without any real regard to what is going where and in what type of car. Not very prototypical for sure, but it can help prove out a train scheduling scheme and get lots of cars moving about. There is nothing really that dictates that only one specific type or class of car can be delivered to a certain industry. It is all 4’- 8 1/2” between the rails and any car can physically go anywhere. After some experience is gained with how the cars move with the trains according to their timetables, more specific roles and car types can be introduced to narrow things down and get more prototypical movements.