Home
Project
Code
Presentation
Journal
Resume
Philosophy
 Senior Capstone

Journal

Date Entry
1/25/2004 I have received my project for my Senior Capstone. The general idea is to create an OS for the Computer Control Railroad (CCR) that manages the various resources associated with the railroad. My initial fear, when dealing with real-time applications, is the burdens that are introduced with the hardware. I enjoy and think I am better suited towards the software aspect, rather than trying to deal with the hardware in such a way to make conducive to software interaction. With the CCR, it seems that all the interfacing with the hardware has been taken care of. Dr Pankratz has informed that that there exist functions that deal with the operating of the hardware and that is the level I would be building up from. I like to think of these "atomic" functions as assembly code, and it seems that I will be using this assembly to create API for the CCR. Concerning the design or conceptual layout of the API, an understanding of OS concepts is a must. The actual implementation will be done through a class system which will require a understanding of basic OOP concepts as well. OS and OOP concepts seem to be the major areas that this project will deal with, of course this is only an initial assessment which will most-likely be underestimated as I start to get more involved. The project sounds very interesting and I am eager to start interacting with the CCR as soon as possible so that I can start brain-storming using the particulars of the CCR rather than lofty and general notions I am limited to now.
1/28/2004 I met with Dr Pankratz and Dr Mcvey on Tuesday (1/27) and we went over the software that Mcvey developed for the train. The use of the software wasn't crucial, but it allowed me to see the situations that the train encounters and got me to think about some issues that i will have to face. One in particular is the issue of the train sliding. If I want the train to stop on a given sensor and it slides, how am I goign to handle that. In the past people have, what i think to be, made an exception and issued that the train would arrive at the sensor again (even though it already did). While that does seem to fix the problem, it isn't consistent with what actually happened. My frame of mind is such that I would rather back up the train so that it goes back on the sensor. If you issued the train to stop on a sensor and it didn't then it seems reasonable that you should commit the train to the original command you gave it, rather than issuing another arrival or departure command to handle the train sliding issues.

So far i've only been working pragmatically with the train and I would like to get into the thick of things and find out what functions are at my disposal so that I can start coding.
2/14/2004 This weekend I spent a few hours developing my Train OS. I'm starting off with the basics and created a class with just two data structures. One is an array that represents the photocell states and the other is an array which represents the turnout states. I've implemented functions that will update that states off these as well as poll individual turnouts or sensors. I have changed some of the conventions previously used because it seems more intuitive. An example of such a change is to interpret a turnout status as either a 0 or a 1 (instead of -1 and 1), where a 0 represents straight (which intuitively seems to be its natural state, "straight") and where a 1 represents curved. While developing, I want to try and create a comfortable enviroment that others can catch onto quickly and not just focus on getting things to work. That, hopefully, is an eventuality, if I can provide the Train OS with "development-friendly" logic, all the better.
2/21/04
Working with changing turnout states. Found out that one can issue a turnout toggle before the turnout has physically been changed. Should I plan on changing this so that one cannot change a turnout until the turnout has physically been changed? The turnout is logically set immediately, however the turnout is not physically set and I cannot determine when the turnout is physically set, only logically. So i could allow for a variable to be set in the system that would wait X milliseconds before one could issue a turnout toggle. This applies to train movement as well. I don't want a train running over a turnout that is in the process of being changed. I don't want to issue a sleep and have everything shut down. I think if I set a bool "turnoutChanging" immediately after I tell the turnout to change and then spawn off a timer that will reset the bool in X seconds. I could then have the SetTurnout() and MoveTrain() functions heed to this bool.

Discovered that there is a split second in between a physical changing of a turnout where the turnout has no specific state. Handling this as returning a -1 so far.

Should there be a track resource between, lets say TO 10-1 as well as 10-3? (For now i assumed not)
3/28/04 For the past 2 weeks I have been working on the TrainOS class structure, researching threads to implement and creating a GUI interface to prove that my OS really works. No major new concerning the class structure. Change certain data structures from structs to classes in order to create member functions that will be needed for them (like giving information about a train). I've been reading up on threads and found some examples online. I don't think it will be too hard to implement. I did a couple tests with some Hello World threads. So my plan is to create a thread in the constructor of my TrainOS object that will continually update the state of the system, and will deal with requests that are made by the trains (processes). The GUI interface design is coming along well. I originally wanted to solely use Dr. McVey's application, and just strip out all the unnecessary sections, but I found that to be too daunting of a task. Taking a look at the application has shown how beneficial my OS will be for further developers, because in the code, the tasks of the general application (painting the screen, dialogues boxes) are intertwined with the tasks of the OS (in this case, the Resource Manager class). It has given me a great perspective on how to design my OS in such a way so that the developer and pay as little attention to the intricacies of the railroad system as possible while developing an application will eventually facilitate such a system. During the GUI development I have been able to work away from the train and so it has given me more time. However, I think that I am a little behind schedule, and that time at the train will need to extend beyond just my weekends. So far though, things are going well, and I think that I have a good handle on the problem.
4/10/04 I made some good progress this weekend. I have had the general OS model setup where the trains were making requests, and the system was either granting them, or not granting them and blocking them. Through the OS's cycle it would check blocked trains and determine if they were able to become unblocked if the resource they were requesting was available. Today's work dealt with testing out the system and debugging. One of the major issues that came up were the intersections on the track. I took care of this issue by "removing" the sensor at the intersection (#6) but also creating a new Intersection object which the OS would check before granting resources. Basically two tracks, lets say A and B would intersect, and within the Intersection object, the OS would check to make sure that if a train owned track A, then it would implicitly own Track B as well, since it is part of the intersection. So I have taken care of that issue. So as of now, I am able to let the trains run loose on the track and the OS is able to take care of everything and have them running properly.

Another issue I was working on was logging. there are 4 "events" that I am logging at the moment, and I will probably add more eventually.

  • Commands issued by the user (Go forward, backward or stop)
  • A train making a request
  • A request being granted
  • A train owning a new track

These events have proven to be helpful when observing the system in operation. An interesting problem occurred after I implemented the logging. I noticed that the response time on the behalf of the OS was longer than it used to be. So that if a train past by a sensor, it would take longer for the system to block the train (stop it). I eventually figured out that the IO involved in the logging (since i'm writing the log to a file) was slowing down the system. So I am going to solve this by creating a separate logging thread that will take care of the writing to the disk, without slowing down the system.

Overall, things are shaping up faster that I thought they would. The next major thing for me to do is to create a command shell to run the OS, and that shouldn't be too difficult.