The New Design:

Originally, C++ was used not only because of my familiarity with the language, but also because I had planned on using more inheritance between classes than the end product illustrates. I had envisioned writing one TrainList class and inheriting this object into two other classes known as ActiveTrainList and BlockedTrainList. This original idea was implemented for a short period, but was discarded when both became member variables of the ResourceManager class. One of the benefits that was discovered later in the semester was that creating a dynamically linked library from C++ was more portable than creating the same dynamically linked library in Visual Basic.

After deciding to discard my old design and code, I discussed different methods with each of the CS faculty. Professor Blahnik instructed me to create new id numbers for each resource on the track. Both turnouts and photocells were to be considered resources. These next resource for a train would be found through the formation of a graph. However, my understanding of this design was that a train would own only one resource at a time. This design did not seem practical to me because I could not calculate when a train was over a turnout. There is no feedback to the computer except through turnouts, and I did not want to construct an operating system to required me to calculate the position of a train given its speed and direction. This type of logic would be both difficult and unreliable given that outside forces like a dirty track could slow down or derail a train.

After thinking about this logic for some time, I found a solution that might have worked. A graph should indeed be used to represent a track. The graph would be ideal to represent the track because it could provide a path from photocell to photocell. During this time, I was drawing various tracks to see if the design would work. The major problems occurred when two turnouts lied together on a track with no photocell between them or the track changed direction by traveling along a path. Neither of these cases were present in the current system, but I felt that they were important to consider. Two lessons were learned from this thought. First, to implement a system with two consecutive turnouts with no photocell between creates a problem. Both turnouts need to be locked and turned in a given way. The current system does not allow for this to occur since the TrackList data type assumes that each photocell reaches only one turnout. One possible solution to this problem for future reference is combine this solution with the Professor Blahnik’s recommended solution. A full graph of the track needs to be designed and the function keeps reading resources from the graph until another photocell is found. That is, if I hit photocell zero I would need to look up in the graph function which resources were next. If turnout one was connected to photocell zero, I would allocate that resource if possible and read the next resource in the graph. The cycle continues until the next photocell could be allocated, or a resource (turnout or photocell) that was requested could not be allocated. In this case the train would be forced to stop and be put on the blocked list. The second lesson learned from this designed was that a track that the changes direction for a train would create many difficulties. When a situation like this occurs an actual short is created on the track and the trains outside wheel becomes its inside wheel. The graph for this situation would need to include data of whether or not a train would need to change its direction around the track. Also since the change occurs over a turnout, a "fake" photocell may be needed to indicate when a train reaches this critical point in the track.

In constructing this design I still did not see how trains could avoid collision. Allocating only one resource to a train at a given point would not avoid collision because if two trains would be traveling in opposite directions around the track and come to the same photocell at roughly the same time there may not have been enough time to stop both trains before a collision. During a discussion with Dr. Pankratz, he convinced me on the design of a train owning two photocells, although he originally explained the design in terms of the train owning a section of track that contained one photocell where there was an invisible boundary that the trains could not pass. During this discussion we discovered how trains are separated if they own two photocells and how these two photocells must be swapped when a train changes direction. This design still worked well with the idea of the graph to provide a function to find the next resource. I implemented a crude simulation of this system shortly after this discussion. This basic implementation can be found on my website.

The Two photocell method:

The two photocell design works because it ensures that there is always at least one section of track (the area between two photocells) between the trains. During this design a train owns both the photocell that it already passed (photocellhas) and the photocell that it will cover next given that it continues in the same direction around the track (photocellnext). In this way a train are stopped when it arrive at a photocell and it cannot be allocated the next photocell that it will need to continue travel. In this case the train would not be able to be allocated this resource because some other train needs this resource as its next photocell. This is what creates the space between trains on the track given the two photocell method.