Help with my University project - Freight Car Routing for Model Railroads


davidpen

davidpen

Long Haired David
Hi everyone. I am currently on my last module to complete a B.Sc. Hons. at The Open University. I am studying "The Computing and IT Project". Well, it is not so much studying as we have to design and complete a project of our own design. I have decided to create a tablet based system that provides freight car routing. Each user has his own "world" on the system. There is a short definition of the railroad and its components. The project then offers you, on the tablet, the switch list for the next train due. I am comfortable with all of the technical side and my tutor is happy that I can do all of that. What he wants me to have is a short list of "clients" that can verify the model railroad side of things.

So this is what I need.

I have put together a web site for my TM470 Routing Project. This will build up over the next few weeks as I get further into the project. I will be building a series of prototypes for the system that will enable anyone to manipulate the software from the web site. However, the main point at the moment is to get some views on the Decision Engine. This is the part that actually constructs the train. You can access the outline of this from the web site and download the White Paper. You can also, from the home page, e-mail me directly to register an interest in being kept in touch with the development of the engine.

I look forward to hearing from you.
 
It looks interesting. The decision engine appears to take into consideration everything I would worry about in making a decision. Actually everything a manager on the prototype would worry about.

My process is alot simpler.
I run a card system for routing. Things like train length are decided in the staging yard, I try to keep them less than 10 cars at this time. Trains on the layout are cut in two if the switcher is unable to pull it.

Sent from my XT1254 using Tapatalk
 
Thank you. I have to record any external contributions and that really helps. BTW, I am constantly updating the web site. There are now a few pages showing object details and hardware layouts. You might like to bookmark the site and come back regularly. I am hoping, in a couple of weeks, to have an initial prototype running. This will slowly extend as I get to grips with the development. The only suspect part is the tablet front end, where I might run out of time in the project. This will mean a wireframe view of tablet operations. I might, though - given I have my own model railroad - continue until the tablet works. As I am retired and this is the last course in my degree, I would certainly have the time.

If there is anyone else out there who would like to contribute, I would be very grateful.
 
I worked on a routing program system years ago for a club using BASIC. I experimented with it, reaction was mixed. I think one issue is dealing with random moves of cars by members that you have to keep track of and have to update into the system. Using car cards we were always resetting them before a run session.
For the program itself, my problem was running into restrictions of the BASIC software data limits. I got the system to deal with multi-railroad interchanging. Differrent "progs" worked the system separately to deal with the routing, one entered data, one did this or that, one set up industry demands, the next performed printing for the members, another updated the system when the train was performed.

But I ran into the limitations so I felt the better idea was to work out something using a data base program using one that can be programmed, thats where I am at today, but my thoughts are, a card system is very simple and effective and can be easily handled by members especially if they are not computer savvy.

I've wanted to make a database program to make car cards but the old savvy typewriter wins out.
 
davidpen said:
However, the main point at the moment is to get some views on the Decision Engine. This is the part that actually constructs the train.
Click to expand...
Your industry data model assumes the same load rate for all types of freight cars. I believe this will cause the decision engine to cycle all the cars at a given industry together. In reality some types of cars could sit through several cycles of a visiting train, while others go in and out on every train.

The decision engine note #3 talks about priority. I don't see a data element of "priority" in any of the data structures to represent the priority of a load in a car. This note also assumes a loaded car has priority over an empty one. This is not true in reality. A loaded hopper of coal is not an urgent load (It could sit there for years without damaging the load), while an industry waiting on an empty car to ship some fresh fruit is a very urgent need. No car to load them in, and they could rot on the dock in a few days maybe even hours.
 
Last edited by a moderator:
Looking at the list of objects, you have a lot of cases where you have fields in two different tables, for example Towns has a field that lists industries in the town and industries has the town at which the industry is located. When you update something you will have to update multiple tables instead of having unique tables linked in queries. Having unique tables means you only have to update one table. Having the same data in multiple tables can result in the tables getting out of sync.

By the way, terminology moment, railroads do not have "towns", highway maps have towns. Railroads have "stations". You can have an industry at a station without there being a town for miles.
 
Step one in the decision engine is "get info on the next train to run". I don't see any table or field in a table that deals with the schedule of a train, that is the sequence of the trains or the sequence that trains operate. From the data objects, I don't see a way for the system to know which train is "next' to run. It may be intended that the actual first step is "user chooses next train to run", but the description implies the system will know or choose the next train.

Step two is to review the cars and locos at the originating yard. How does it know what the originating yard is? Are you assuming that the first train in the list of "towns" in the route is the originating station? If the train is a turn (originates at Anna, runs thru Bess to Cloy, works, then runs back thru Bess to Anna) it will originate and terminate at the same "town". The scheduling logic will have to be able to handle an origination and termination at the same station plus passing through a station more than once. Worst case is a local that originates in the middle of its run. For example on my layout there will be a switcher that will originate at 6th St Yard, run to Pigeon Point, switch, come back to 6th St, set out, pick up, run to Kentmere, switch, come back to 6th St and terminate. So 6th St is an origination, termination and intermediate work location. Not saying that you can't accommodate that or even that you have to, but it is an a possibility.
 
In step three it reviews the route to see if there are cars to be picked up. If I run multiple trains that serve the same towns, how will I spread the cars out between the jobs. I want the wharf to be worked by the 2nd shift engine. The first shift and 3rd shift engines also work the same towns the 2nd shift does. How do I get the wharf cars to only schedule to the 2nd shift engine?

Does your system have any concept of unfulfilled demand? Does it look for cars to fill orders anywhere on the layout? For example. I have an industry that uses airslides, but I only have 2 on the layout. One is one spot loaded and not released, the other is empty and at an industry. None are in the yard. The engine looks to see what the demands are at the industries and Acme Sugar can use an airslide, it looks at the yard to see if one is available. None are. Does the system just skip that order and go on, does it tell the layout owner that it wanted to spot an airslide, but there weren't any available, or does it see there aren't any in the yard, but there is one available at another industry, so sends that car to Acme?
 
Routing in a real system is handled through the schedule because real railroads attach more attributes and have to worry about time.

On a real railroad, the schedule would have the schedule name, category, a station sequence number, station number, arrival time, departure time and work attributes (separate fields for set out, pick up, industry work, interchange, fuel, inspect, crew change, etc). The table would have the columns as the fields described above, with the rows an individual station for an individual schedule name. A "schedule' would be a query filtering for the schedule name, sorted by station sequence number. A real train that reported events (train arrival, departure or passing) at 20 stations would have 20 rows in the schedule table. On a real railroad the schedule name had four parts, section, symbol, day and date. Probably overkill for a model railroad.

A "dummy" schedule would be a generic schedule for a route and then a train schedule would be a copy of that schedule, but with the details and start time adjusted (all the times would offset based on the start time).

Food for thought.
 
You must log in or register to reply here.



Back
Top