Friday 18 November 2016

My Open University Proposed Project

I am signed up for TM470 - The Computing and IT project. This starts in January but before then I have to have a proposal for a project which will take 30 weeks to carry out and result in a 10,000 word report. It must be associated with at least one of the Level 3 (Honours level) course that have been followed and it has to be technology related. I spent some time a couple of years ago working on an idea for a freight car routing system. I managed to get a very thin prototype working which had the following constraints:
  • Capable of handling a small railroad
  • Very limited in its routing options
  • Minimal user interface (web based)
It did, however, prove that the idea was feasible. Now, I have to take it to a new level of operation. Well, in fact, I only have to design the project and report on the design. It would be good to have a prototype of the tablet front end and of the routing generator (which is the most complex part of the project). I can't get away with stating that I know that there are other issues that affect car selection and routing as I will be expected to have carried out a thorough analysis of the issues and choices which should be reflected in the design. Anyway, here is what I proposed along with a second post that expanded on the problem domain. Please note that this is written for an audience that a) doesn't know anything about railways and probably isn't interested and b) is based in the UK so doesn't know anything about US railroads - including the terminology that is obvious to us. The background description is purposefully brief so please ignore any obvious "facts" that have been missed.


Freight Car Routing On US Outline Model Railroads

Project Background

US manufacturers etc. are traditionally connected to a “railroad” by local sidings similar to container shipment delivery by road, now. Individual US industries, within towns/cities would be connected to the railroad by their own siding (maybe shared with others) and receiving/sending goods by “freight car”. These sidings would be sited within two “Division” yards. The railroad runs “Way Freights”  between Division yards that are given lists of cars to deliver from the main freight yard to various industries and collect cars from those industries when ready. Freight cars are sourced from other industries on the same railroad or from other railroad systems by an “interchange”.
Additionally, there will be freight trains that move cars between division points. The software will also have to provide for the make up of these.
The proposed system would hold a schedule of all trains and be able to prompt for the next train to be run against that schedule. The railroad will, possibly, run passenger trains within its schedule (even if managed by an outside agency such as Amtrak). The system should allow for these

Model World

  • Requirement to run trains realistically
  • Problem of generating random but sensible outcomes. Becomes harder as the size of the railroad increases. Some (many) model railroads in the USA can exceed 60’x40’ (18m x 13m) so the problem can be of great complexity.
  • Requires  a well-designed workable user interface during operation.

Problem Outline

Designing a multi-user software design for Model Railroad Car Routing

  • Creating the background scenario – available rolling stock – industry destinations – track and train capacities – frequency of service within a database.
  • Creating a rules based software engine design that incorporates random elements to allocate freight cars to locomotives/trains/industries.
  • Able to deal with small railroads as well as large.
  • Creating a flexible user interface for data uploading of railroad stock and industry data for each user.
  • Creating an easy-to-use tablet based touch interface for using the system during railroad operation.

Implementation

Project to be an Object Oriented software solution providing

User front end (tablet/phone based) – iOS Swift or Android

REST back end server – “Smalltalk/Seaside” based (my in-depth language)

Fast, simple database – likely to be a Key/Value NoSQL – possibly Riak KV

Deliverable to be design and implementation plan ready for coding.

Glossary

Railroad – US name for a railwayFreight Car – US name for a railway goods wagonDivision – One part of a railroad. Railroads normally comprise of a number of divisions – normally crew and/or engine change points.Way Freight – A Goods train that comprises wagons for delivery at various industry locations along a part of the railroad between home depots. It also collects wagons that have been processed – either loaded or empty – loaded for onward delivery – empty for return to the goods yard.Interchange – A point on a railroad where two companies connect and thus can exchange freight cars for onward delivery – either to a location within the accepting railroad or for onward transmission to a ”foreign” road.Foreign – US railroads are all privately owned. There are approximately 700 railroads, all of which connect to one or more other roads. A foreign road is any other road than the one currently holding a “car”.Car – short name for any railroad rolling stock – hence freight car – passenger car, etc.

Amtrak - Wikepedia - https://en.wikipedia.org/wiki/Amtrak
Smalltalk – Wikepedia - https://en.wikipedia.org/wiki/Smalltalk
Seaside – Wikepedia - http://www.seaside.st
Riak KV – Basho - http://basho.com/products/riak-kv/

Addendum

As some misunderstood what the central problem was, I expanded on the routing generator as follows:

The complexity is actually from the routing issues:
  • A track can only take a loco, a caboose (brake van) and a maximum number of freight cars (depending upon the train type selected).
  • An appropriate loco and, maybe a caboose, must be available (modern trains do not require a caboose).
  • Each freight car needs a destination.
  • The destination has a maximum car limit as well.
  • The destination maybe has a/some cars there already.
  • Industries have car types and loading/unloading times that need to be observed.
  • Some of the cars at the destination may be ready to be moved.
  • If we move them, is there now space for a new car
  • A car, when selected, may have the following:
    * a new destination (possible if the car is loaded or empty)
    * released back into the free pool (if empty and own road)
    * moved off the system towards its home road (if a foreign owned car).
  • and round we go again!
and so on...
It really doesn't matter if there are 5, 10, or 50 possible locations as the limit is set by the train length.
This, in itself, is set by a few factors - the power of the loco, the weight of each car and also, because it may meet other trains en-route (most US railroads are single track), the length of a siding that it can get into to get out of the way. The power of the loco isn't that important as you can always connect a second (or even third or fourth) loco. It is the siding length that is the ultimate limiter. 
The smart part of the router will be coping with a possibly large number of cars in the pool. I have some statistics that show 250 cars available for use on a model railroad!
I will keep you informed as this progresses.


No comments: