Stakeholder comments

As part of the project, I have to solicit contributions from 3rd parties that may or may not have a “stake” in the final outcome. As I have not succeeded in gaining any local, personal, involvement, I have had to go out to the community at large via the various model railroad forums. There are problems with this approach as it isn’t really possible to ensure that the concept of a “project” as used in TM470 is understood, that the scope of the project needs to be constrained due to time pressures, that it is not intended to model the real world in its entirety or that it is not destined to be a commercial product.

There is another issue – The model railroad fraternity demographic is heavily weighted to the senior end of the scale – people with time, money and skills. This puts their professional computer technical knowledge in the “I used to” category, mostly. Few have kept up to date, unlike myself who has needed to stay current in order to complete my honours degree (and to make my living). The technical contributions have mostly missed the point of what I am trying to do.

However, I did get some contributions so I felt that it was worth discussing these. There are too many words for this to be included in the current assignment (TMA03) so I decided to present them as a Blog entry and reference the whole page from the TMA.

Contributions to this blog


Have you considered the “off stage” portion of the layout as multiple destinations? The idea in my mind would be that it would better represent a connection to the rest of the world rather than simply “staging”. It would be simply that, of course, but the origin or destination might be Seattle, Ogden, Los Angeles, etc. – Neil Erickson

LongHairedDavid – In reply to sarahdaddy.

I had but hadn’t got around to clarifying it. However, as far as the software is concerned, everything is routed to Hartford or Boston (in my test scenario). The real world doesn’t exists and the software is only concerned with the physical model so it doesn’t matter if a reefer is actually going to New York – Hartford is good enough for us.

Model Train Forum

1905dave 05-28-2017, 04:42 AM

What happens when your railroad has more than one yard on a division? My layout will end up with 3 yards on the same branch, one at the junction, one at the end and one in the middle.

LongHairedDavid – In reply to 1905dave

Trains can originate from any yard. However, cars on trains will not be assigned to a yard destination (that doesn’t make sense unless it is an empty being returned to its home railroad (out of scope for this project). Empties be taken to the final destination yard whilst loads will have their own destinations. Extra yards do not change any of this.

1905dave 05-28-2017, 04:42 AM

There are 3 types of industries, one only outputs like coal, another brings in loads of lumber and glue and outputs furniture as an example, the next would only input like a coal power generating system. Any reason why you didn’t just make all the industries type 2, both receiving and shipping? For ship only you just don’t define any inbound loads and for the inbound only you just don’t define any outbound shipments. It just seems like it would be simpler.

LongHairedDavid – In reply to 1905dave

“For ship only you just don’t define any inbound loads ” That is what the flags on the car record do. They stop the creation of final destinations for empties (unless one is set).

Model Railroader Forums

05-24-2017, 11:14 PM

I can’t contribute anything to your project, but I wish you all the best of luck!:)

05-25-2017, 01:46 PM

Its interesting that you don’t think the databases need to be normalized, especially since the prototype ones are.

05-26-2017, 07:19 PM

Not using a SQL database. On a Key/Value database, there isn’t any normalising. You have multiple copies of data under different keys.

05-27-2017, 12:58 AM 

On a key/value database, if you change something don’t you then have to track down all the places that field exists and change the value in multiple tables?

05-27-2017, 12:56 PM

Only if you are using it as though it was a SQL db (which would be pointless). KV databases are used for fast access by keys – not by searching. There are objects in buckets accessed by keys. You use it by dumping and reading complete records (not an expression that I like – I prefer “objects”). So, in my prototype, there is very little data that gets changed for each train creation. Think of a railroad with 100 locos and 450 cars. At any one time, you are building a single train with 3 locos and 50 cars, say. That looks like a lot of data to be saved as each car needs to know what train it is on and where it is going. However, each car record is minuscule and without the payload of a SQL record. Modern servers can write that lot out almost instantly. – 3 loco objects updated, 50 cars re-written, one new train saved. When you want the data, the train holds the ids of all the cars and locos so no searching required.

05-28-2017, 04:52 AM

I was thinking more along the lines of let’s say I have a station “Coateville”. So, all the routes and all the customers and cars at that station get the station name applied. About the 3rd session, I notice that I misspelled it and it should be “Coatesville”, with an S in the middle. Wouldn’t the system have to check every record in every table in the database to correct the spelling? Trivial example but it can happen and if you match on spelling it can create mismatches if its not consistent.

05-28-2017, 09:42 PM

I think that you are thinking about traditional databases. The only thing that matters in this scenario is “this train”. The system builds the train for you. You use the information; tell the system that you have moved all of the items; the system updates for the new locations and then that whole action is forgotten. There is no concept of a history report – who cares what happened 10 trains ago?

05-31-2017, 08:08 PM

If you don’t have an empty reefer in the yard, at least in the first iteration, you will never spot a reefer to the industry because it will be dropped. Even in the future version, it will just roll the demand to the next train. If there were unfulfilled orders for that cycle it would continue to roll them to the next train and so on. The problem I see with this is that if you have the engine proposing a higher demand than there are cars available, the owner will never know he is short of cars, and conversely if he never knows the engine is generating a higher demand, he won’t know to adjust a parameter if the engine is generating too high a demand. The system should tell the user that there were XX cars assigned to spot, but YY orders for cars that were unfulfilled. Similarly, there needs to be a report that indicates there when cars were trimmed from a train due to length or power.

05-31-2017, 08:20 PM

Short of cars isn’t an issue – so the train runs light. Must happen in the real world. Too many – good point but we aren’t running a railroad, only a model so generating lots of lists for things that didn’t happen aren’t really necessary. If we generate 5 cars extra for every train, it would mean that, somewhere, there is a parameter that needs tweaking, rather than “Fred Brown is late getting his two box cars so we must ensure that we deliver them ASAP”. Remember that most people run a model railroad for a couple of hours and then come back to it sometime. Being reminded that there are 50 cars so far that haven’t been shipped isn’t really part of the “model” scenario.

I have lightly t the above and have omitted lots of extraneous content proposing functions that are outside the scope of the project. This is mostly because the contributors are forgetting that this is trying to run a model railroad and not model a real railroad.

Posted in Uncategorized | Leave a comment

Week ending 2nd July 2017

Monday 26th June: See Tuesday!!!!!

Tuesday 27th June: Well, this is crunch week. I need to have the software behaving itself and the TMA written by Sunday. I messed about a lot of Monday clearing little bugs and am doing the same today. irritating things that should have been seen as I went along.  Currently, at 12:37, I have just about cleared the last bug for the different train types. Now, the train count has gone back to 0 (0 should never be!) after eight trains when there are twenty in the schedule. Keep going. At least, I have 3/4 of the TMA written.

Wednesday 28th. Done. Software creates all 20 trains and then recycles back to number 1 again. That was the target for this iteration so the coding is done. Now to finish the TMA.

Posted in Uncategorized | Leave a comment

Week Ending 25th June 2017

Monday, 19th June.

Spent all the time today working on the TMA. Using TMA 02 as a master and adjusting, correcting, deleting and adding as required.  About 30% complete, I would think.

Tuesday, 20th June.

decided that I can go back to normal studying routine of 5 days a week for 2 – 3 hours, rather than spending all day, 7 days a week, which is what was needed to catch up after working on TM352. Currently working on the code to expand the train types from the sole “way freight” type through the rest of the types.

Well, that was fun. I was having trouble testing the flow of trains through the timetable, so as a temporary measure, I have put in a link to reset the database to its startup state. I have done this as a REST link (GET) so it can’t stay but then,  any reset ought to be done under more controlled conditions (which are outside of the scope of this project as this function wasn’t included in the project outline).

The next train type coming up is the through freight, which should load up a semi-random number of cars from the base yard and take them to the destination yard, maybe with some drop offs at major yards along the way. I have the code sorted but needed the reset to enable me to continue to test it. Back onto this on Thursday morning.

Wednesday 21st June

11.00. Change of plan. I have two hours today to work on the Through Train definition. First thing to do is to get the randomiser working the way I need it.

11:16. There is now a randomiser for the total freight cars.

11:54. Trying to run a series of trains and getting in a mess. Time limited this morning so I will stop and pick it up again this evening. I will update Wrike! though.

Thursday 22nd June

Change of plan – again – didn’t get anything done last night but not going shopping this morning so a few hours to get this right.

Posted in Uncategorized | Leave a comment

Week ending 18th June 2017

The week started off nice and early so that I could get a lot done. The plan is to have all of the software written this week for the Decision Engine so that I can get program the POST operations that are required for static amendment of the data (i.e. not by the logic – this is useful if manual placement of cars doesn’t match the data held on file) and then get on with the TMA.

It hasn’t worked out that way because of the large effort on Sunday to restructure the database to match the new test layout. Having been away for some time, I am having to remind myself of how the manual loading processes work. I should have build some scripts to do this but have relied on test scripts within the main  code. My arthritis is also making my brain feel like mush so this is hard work. Still, I have a whole week to get this sorted. I am only out for Monday afternoon and Friday morning so there ought to be enough time to get this sorted and have the logic code underway.

Monday 12th June 11.14. Completed restructuring of data. All data now verified in Excel, stored in Riak and presented through web pages off the Main menu (local version only for now. Into release version on 13th June). Completed adding location drop down to required pages. Now need to complete the PUT web operation so that the results can be saved back.

Tuesday 13th June 10.22 – Commenced work on http PUT. It is 15.37 and I have spent all this time trying to get the whole system to work. Having changed all of the data definitions, I missed some of the places where changes were needed. I stopped. Did a review of what was needed and then carefully went through and fixed all the issues. There were a couple of instances where I had broken my rule of having everything separated into their own servers. I fixed those instances as well so we are now back to a working system with the integrity back in place.

Wednesday 17:11. Finished. The POST/PUT was quite difficult to put into the system – the main problem was maintaining the username across the various page changes. Done now. The moveable items can all, now, have their location changed on a page. This will be needed when we come to the mobile phone/tablet version. Tomorrow afternoon I can get on with the decision engine. I am desperately making up hours lost to TM352.

Friday 11.44. I intend to spend the rest of the day getting the first run at the DE. First off, I have to set up the cars to be in place. I then need to boilerplate the code so that I can run the timetable. This will enable me to set all of the parameters ( such as time on site) needed as the trains are created. Once I have run a full timetable with this, I will start to flesh out the code.

Saturday 10:50. I failed to progress yesterday, mostly due to my arthritis. I have decided to start again with a clean sheet for the train creation. All previous attempts have ended up too complicated to achieve in the time frame available so I am going to reduce the specification. The result will still be a working routing program but will have some of the “bells and whistles” left for a later pass.

At last, I have got somewhere. I can now create a local freight with cars, a loco and a caboose. In fact, there are no cars because, as currently set out, all of the cars are on the of site staging and not on the railroad. If I run this process through a full schedule, we should end up with cars spread randomly around the layout. Then the second run will give us a better test.

Sunday 10:20. Last day of the week and some real progress this week. Finally got my brain in gear and managed to overcome the arthritic fog that I suffer from quite regularly. I now have one version of the Way Freight process done. Today I am going to work on displaying the resulting train and updating the physical positions of everything once the “real world” train has been actioned. If I can get that sone quickly, I will move on to the next train in the schedule. This is through freight from one division yard (off layout staging) through to another division yard (another off layout staging) – with a stop off in the middle. A bit less complicated than a way freight.

Posted in Uncategorized | Leave a comment

“On Paper” definition of Off Railroad train creation

Stopping Freights

Train = get Next Train definition
Verify Loco/Caboose Availability
     If OK then
            Create New Train (Train)
            Apply Loco/Caboose
            Using List Of Towns On Train
               Random select industries for new empties or loads
                 up to 100% of Train/Size (TS)- 
                 only selecting where car available in staging
TBD - Assess TrainWeight (TW) against LocoPower (TP)
      Add Locos if needed and available
      Finally assess TP against TS and make final adjustment
Display Train
Confirm Train has been run as expected
Update Loco/Caboose/Car locations and industry car details.

Back to Blog Week Page

Through Freights

Train = get Next Train definition 
Verify Loco/Caboose Availability      
       If OK then
             Create New Train (Train)
             Apply Loco/Caboose
             Random select from cars available in staging
             using a random car total up to 100% of Train/Size (TS)
TBD - Assess TrainWeight (TW) against LocoPower (TP)
       Add Locos if needed and available
       Finally assess TP against TS and make final adjustment 
Display Train 
Confirm Train has been run as expected 
Update Loco/Caboose/Car locations and industry car details.

Back to Blog Week Page
Posted in Uncategorized | Leave a comment

“On Paper” definition of On Railroad train creation

Train = get Next Train definition
Verify Loco/Caboose Availability 
     If OK then
            Create New Train (Train)
            Apply Loco/Caboose
           Using List Of Towns On Train
                 Check each industry for loads ready to go
                     in the right direction(LRTG)
                         (ActualTimeOnSite >= TimeOnSite)
                 Add all LRTG to Train/Loads (TL)
                Check each industry for empties ready to go
                     in the right direction (ERTG)
                         (ActualTimeOnSite >= TimeOnSite)
                 Add all ERTG to Train/Empties (TE)
                TNL = TrainNewLoads
                Random select industries for new empties or loads
                 up to 50% of Train/Size (TS)  = TN//50% constant -                   may change
          Assess TS against TL+TE+TN (TT)
         If TT>TS then random reduce all three parts to fit.
TBD - Assess TrainWeight (TW) against LocoPower (TP)
      Add Locos if needed and available
      Finally assess TP against TS and make final adjustment
Display Train
Confirm Train has been run as expected
Update Loco/Caboose/Car locations and industry car details.

Back to Blog Week Page
Posted in Uncategorized | Leave a comment

Decision Tree 1.0 – 6th June 2017

For now, I am going to concentrate on freight trains. I will address passenger trains later in the course (if there is time).

There are two main types of train that we need to manage:

  1. Trains that originate on the model railroad and
  2. Trains that originate of scene.

There are two main differences:

  1. To create a train “on scene” only cars that are currently “spotted” (either at an industry or in a storage yard) can be included in the process whilst “off scene” trains can only be created from cars currently held on storage tracks (known as staging).
  2. Trains both on and off scene can take cars and drop them on staging (i.e. without a specific destination) provided that their final destination is staging.

So, what do we do:

On the Railroad origination

  • Collection of loads at industries for onward delivery;
  • Collection of available empties;
  • Requests for empties by industries.

The train length is defined in its database description. The process should randomly decide in which order to carry out the above three processes so that each train has a slightly different emphasis.  The actual train length will be adjusted to a random length(within the defined maximum).  The decisions are as follows:

  1. Loaded cars (empty status = true)* – time on site >= location load time;
  2. Empties (loaded = true)* – time on site >= location load time;
  3. Assess all locations for space/requirement for empties – add to train up to random length.
  4. If number of cars exceeds random length, each of the three elements is adjusted down as required.

Off Railroad origination

  • Assess available space along the route for space for new cars
  • Assess the available cars in the train originating staging location and match cars to spaces up to the random length of the train (see above).

Train Type Analysis

There are two main types of train that can run and this type affects the choice of cars and locations.

  1. The archetypal “Way Freight”. This will stop at all towns between A and B so all car allocations should take this into account. These, when originating on or off railroad will use the process discussed above;
  2. Through freights. These run through between division points and stop, if at all, at a limited number of towns. When run off railroad, they will either finish on railroad, in which case they will use the complete process discussed above. When run end to end;i.e. staging to staging, only the second process is applicable.
  3. Manifest/Symbol freights.  When run on the railroad, these shift cars in blocks between these division points. Currently, as this is only applicable to large model railroads, this option will be omitted from the specification.

Note re: database design

Location records must be amended to define whether that location accepts loads only, empties only or both. (edited 11/6/17)

Location records must be amended to add an extra field (whenLoaded)to indicate where loads should be shipped to. (added 11/6/17)

Car records must be amended to add an extra field (whenEmpty) to indicate where the car should be shipped when empty. (added 11/6/17)

Posted in Uncategorized | Leave a comment

Week ending 11th June 2017

5th June

Started to re-organise the project plan. Due to losing quite a few days, I have had to rethink how I am going to get the rest of the course completed in the manner that I originally envisaged. I have had to remove some of the intermediary testing steps. This isn’t too important as I work to a rigorous testing regime whereby no method is closed down unless I have tested it and all its affected parts. This means that I expect not to have any bugs bite me later on.  The original schedule looked like this:

Secondly, I have had to remove the data structure analysis. I don’t think that this will matter as the current one is well thought out and will work for any expanded version.This is mainly because the database for any user is quite small – even for a large railroad. Riak KV  can serve users with thousands of keys and data very quickly so this application is not likely to stress it.

The main aim, as I see it, is for a successful conclusion to the project out in September with a working tablet interface (prototype only maybe) that interfaces, using REST, to an efficient decision engine and key/value database to provide freight car routing against a timetable of trains. This will meet all of the requirements for reference to previous OU courses and for the original aims of the project.

The project plan now looks as follows:

From tomorrow, the plan will be to work on the DE for the next two weeks, reporting daily on the progress via this blog.

6th June 2017

I have had to do some thinking about how this project is going to work.I have had lots of comments from knowledgeable people about how it “ought” to work but most of these have missed the most important things about the project.

a)  It is a course that provides a written report, not a course to supply a working piece of commercial software.
b) The software is to manage a model railroad, not a real one. (It was suggested that, if the software generates a request for an empty and that there wasn’t enough room on the train for that car, this should be retained for addition to the next train – as though the requestor is a real business.)

It would be nice to incorporate every real world action but, firstly, that isn’t the aim of the software and, secondly, there isn’t the time or the scope to do such a thing. After all, the aim is to create an idea, define it in software terms and demonstrate its achievability and to write a final report about the process to gain a good pass on the module. Should there be a nice piece of software at the end that would run my model railroad – well, that would be a bonus!

OK, so I have sat down with some paper and a sharp pencil to try and define quite how far I want to go with the decision process.

(Click on either image for a full sized view).

As a result of this little bit of scratch planning, I have worked out a decision tree.

To save space on this blog entry, I have created a separate page for this.

7th June 2017

I collated all of the forum comments ready for some analysis. They are in a separate Word document and will be supplied as an appendix to the upcoming TMA. I will provide a summary of these later in the week.

In the meantime, I have been editing the CSV files that are used to seed the database.  The main reason for this is that the layout shown on the blog no longer exists. I had difficulty using it due to my arthritis (it was too high and standing is a problem for me). It has been dismantled and rebuilt at a lower level. The previous layout had  some very tight curves that were causing problems with derailments so, instead of a “roundy-roundy” form, it is now end-to-end with, what the Americans call, staging at both ends.


This has caused me to review the CSV files that describe the layout and make the changes required to reflect the new traffic patterns. I have updated the “industries’ file and there are now 21 possible locations. The “locos” file now includes the two extra locos that have appeared since Christmas. I have also purchased some passenger cars as, previously, these were left out of the process. This means that the “routes”and “trains” files have been updated to include a “Boston & Maine” (B&M) passenger return trip. As I only have one B&M loco, I have to ensure that it will be in the available at the right location when it is needed for both passenger and freight trains. This will add another twist to the problem. The first thing to do is to make a running chart of the trains as currently defined.

Now, I have to put into this a journey from Boston to Hartford and back using the B&M loco 1536 as this is the only B&M loco that I have. This action resulted in a few changes but the final version was verified with another running chart.

Without running the trains we won’t get a feel for whether  this is right. I think that there will be some changes but this version will do for now.

Not only have I had to change the trains but I have also had to review the industries spread around as I now only have two locations rather than the three in the previous layout. I have also decided that it is easier of each car type gets its own entry rather than having multiple car types for a single industry. Here is the final (for now) version.

id name type location carTypes waitTime Send To
1 Classification Yard Sunset allFreight 0
2 Freight House Industry Sunset allFreight 1
3 O.H. Wright Industry Sunset boxcar 2
4 O.H. Wright Industry Sunset flatcar 2
5 O.H. Wright Industry Sunset gondola 2
6 Sunset Gen. Manf. Industry Sunset boxcar 2
7 N.E. Ice Industry Sunset reefer 1 reefer
8 Loco Oil Industry Sunset tank 1
9 Creamery Industry Sunset reefer 2
10 Creamery Industry Sunset boxcar 2
11 E.C. Fuels and Oils Industry Webster tank 2
12 E.C. Fuels and Oils Industry Webster hopper 2
13 Greene’s Feeds Industry Webster boxcar 2
14 Freight House Industry Webster allFreight 2
15 Blums Lumber Industry Webster flatcar 2
16 Blums Lumber Industry Webster gondola 2
17 Burgess Manf/ Industry Webster boxcar 2
18 A.N. Other Industry Webster allFreight 2
19 Boston1 Staging Boston allFreight 0
20 Hartford1 Staging Hartford allFreight 0


  1. There is a new column – Send To. This is required because the type of freight car in question needs servicing before it can be used. The only one here is the refrigerator car (reefer) as this (in the era we are working) needs to have ice blocks insert in special channels to ensure that the car is cold for its service. This, when requested by an industry, it must go to theIcing Company first.
  2. Those entries with zero as their wait times are storage yards that have large capacities  and are effectively unlimited in this context.

8th June 2017

Today, I am going to commence the planning for programming the new trains.  This is going to be done in two parts

  1. On Railroad/Train
  2. Off Railroad/Train

but I only expect to get  1. done today. I will define it “on paper” and do a theoretical run through. Once this and2. are complete, I will start the programming – expected on 10th June 2017.

Part 1.0 On Railroad is  provided on a separate page – HERE.

Part 2.0 Off Railroad is provided on a separate page – HERE.

11th June 2017

Spent s difficult day getting back to grips with the software, not having touched it for a few weeks and having my mind on Javascript. Over the last couple of days I have been busy reconsidering the data that is needed. This resulted in quite a few changes to the data definitions. hence, I haves pent a long day today (11am to 4pm) going through the routines that load data from the CSV files I use to create the data and convert them into Riak JSON data. It is pretty much sorted now so tomorrow I will be able to get going again with writing the software for the decision Engine.

Posted in Uncategorized | Leave a comment

Back on the road

I have had to take a few weeks out of my TM470 project timetable due to the need to get to grips with Javascript. I have been studying TM352 – Web, Cloud and Mobile Technologies –  as one of the last modules required for my honours degree. I also wanted to complete the module before getting on with this course as part ofTM352  was teaching us to write apps for mobiles. As it turned out there was almost no teaching. They just gave us an assignment that assumed that we could write Java and Javascript. The End of Module Assessment (EMA) also required these skills so, me have none of them, had to scrabble around finding out how it all worked so that I could even attempt a pass. I managed – sort of – and the EMA is now in and the course is over so I have just this module to worry about until September, when it finishes.

I have decided that, although I have been using the blog to illustrate the ideas and thinking behind my freight car routing project, I have not found a satisfactory way of recording the progress as is required. Hence, I am changing the blog to be a daily/weekly record of my activity and,along the way, expanding on my thinking and planning.

The next Tutor Marked Assignment is due on the 4th July, which gives me four clear weeks to carry out the next portion of my project. This had two aims:

  1. To complete the REST implementation by including a PUT capability into the interface. This will enable me to build a manual correction facility for railroad car placement at locations.
  2. To implement as much of the Decision Engine (DE) as can be achieved to enable real, random, car routing, alongside a timetable, to happen.

Additionally, I have been actively seeking external input to the ideas. This has been somewhat successful in that there have been a good many responses to postings asking for input but not much of it has been any use in planning the DE. I will dedicate a blog page to the inputs that I have received – and mention some of the well meant but inappropriate efforts to help.

Firstly, however, I have to lay out a plan for the next four weeks. I have to submit a Tutor Marked Assignment (TMA) of 5,000 words (not including appendices). The important aspects are  given to us as “Learning Outcomes” (LE).  The best marks are to be earned by ensuring that these LEs are met in full.  It is a bit of an art organising a report on the project that, hopefully, describes what has happened, how it meets the project goals and how one is expecting to get to the end from here – and meets these LEs successfully. The LEs for the upcoming TMA are:

Problem description

  • nature and context of the problem
  • proposed solution or recommendations
  • analysis of likely impact
LO2. Identify and refine the goals and content of your project


Account of related literature LO4. Gather, analyse and evaluate relevant information to complete the project successfully

LO6. Make effective use of a variety of information sources including the internet, demonstrating awareness of the credibility of the source

Account of project work and its outcome LO1. Demonstrate and apply a systematic understanding of the fundamental technical concepts and principles relevant to your project

With these in mind I need to sit down and work through my current notes and files.

Posted in Uncategorized | Leave a comment

Decision Engine – Second Phase Scenarios

Now that we have sorted out how the main functions of the Decision Engine (DE) work, it is time to look at the customer demands. These are what drives the railroad after all.

The local meat packers has a stock car of beef due from Chicago. Once this has been handled, they need a refrigerator (reefer) car to take out some of the produce whilst two box cars are needed to take the rest of their week’s production.

All references to locations and industries are those located on the test layout shown earlier. Chicago is to the west of the railroad so a loaded stock car would  be brought on an east bound freight to Hartford. The next freight train due from Hartford will bring it to Sunset. Staging (See the glossary below) has a special rule for allocating cars which will be discussed later.

The stock car is easy. We create a demand from the packers, which is resolved by allocation of a stock car on the Hartford staging. Empty box cars come from the general pool so can be sourced from either end of the railroad.  The reefer is required to be cold (in these times, reefers were loaded with blocks of ice to chill the interior) so would have to be sourced from the Ice House at Sunset. Thus, a request for a reefer actually causes one to be allocated to the Ice House for at least one half of a day before it can be shipped to the meat packers. Again, if a reefer should not be at Sunset, an empty one would need to be sourced from either end of the railroad.

This makes three different types of action, all of which have to be allowed for in the DE. Another type of operation would be typically needed by coal mines, for instance. An empty hopper is delivered to the mine and then loaded. Loaded hopper may well ship to multiple destinations. However, this operation is empty driven whilst one of the operations mentioned above is load driven. This is a crucial distinction in the DE.


Staging – parts of the railroad designated as “off scene”. They are normally used to represent other destinations and normally comprise one or more straight tracks out of sight to be used to store trains. In our test layout both Hartford and Boston are represented by staging. In our test scenario,they are actually one and the same staging tracks. Because they can be switched (shunted) by the “big hand in the sky”, it could be permissible that any of scene freight car can be sourced from any staging destination. On larger railroads, this would not necessarily be true.

Posted in Uncategorized | 2 Comments