Good Example Of Research Paper On Train Schedule Planning:

Train schedule planning is a challenging activity it involves projecting the daily operations in a railway network. The input for train schedule plans is usually based on long-term arrival and departure scheduling at the station, track maintenance scheduling, train routing, rolling stocks and other special considerations that need to be accounted for when preparing daily train schedule. Currently, planning is done and revised on paper prototypes after which the outcome is simulated on computer systems (Fransoo, Wäfler and Wilson).
When developing a Train Traffic Management System, the concept of a train plan is therefore very crucial since there’s one active plan for each train and each plan is assigned to one train only that may involve different orders and track locations. Developing a train plan involves consideration of the potential clients in the plan and how each is expected to use the plan. Some clients may have creation and modification permissions on the plan while others have read-only access. In this regard, the train plan is the repository for all relevant information associated with a train’s route and the activities that occur during transit such as collecting or dropping off cars.
Figure 1 shows the strategic decisions regarding the TrainPlan class structure. The class diagram is meant to indicate components of the train plan, and it is observed that each train plan consists of a single crew that may have several general orders and actions. The actions are expected to be time ordered, with each action comprising details such as speed, time, location, orders, and authority. Examples of actions in the train plan are shown in Table 1 (Booch et al.).
Figure 1: Class diagram of the TrainPlan class (Source: Booch et al.)
In the Figure 1 above, there is a UniqueID in the TrainPlan class to uniquely identify each instance of the TrainPlan class. Since the aggregated information is complex, classes in the diagram that might have been considered as class attributes are, in fact, stand-alone classes. For example, the class, UniqueID is not only an identification number but also has the attributes and operations required for compliance with national and international regulations. Crews also have work restrictions such working locations and adherence to speed limits at specified times and locations (Booch et al.).
The most crucial elements of the TrainPlan class can be designed early in the development process, and the evolving attributes added over time since plans are actually applied to different types of clients. The presence of active and inactive plans at any instance raises database complexity issues, and the TrainPlan class diagram can be used as the outline for the database’s logical schema. In an ideal world where communication interference in non-existent and computing resources are infinite, it is possible to store all train plans in a single, central database. Using the above approach, only a single instance of each plan is yielded. However, in the real world, the solution is impractical since communication delays and limited computing resources do exist. In this regard, accessing a plan in the dispatch center does not meet the real-time requirements of the system. However, the illusion of a single centralized database can be implemented using software, and this involves having a train plan database in the dispatch center computers and distributing copies of individual plans to required sites in the network. Each train computer also retains a copy of its current plan for efficiency purposes since the onboard software queries the plan with minimal delays. If the plan is altered at dispatch or by the train engineer, the software synchronizes all copies of the plan (Booch et al.). This scenario is a function of the train scheduling mechanism shown in Figure 2.
Figure 2 Train Schedule Planning Diagram (Source: Booch et al.)
The master copy of each train plan resides in the centralized database at dispatch, and zero or more copies may exist at different network locations. If a client requests for a particular train plan copy, the master is cloned, and the copy sent to the client on the train which makes changes e.g. due to the train engineer’s actions. The client makes alterations in this plan, and messages are also sent to dispatch to modify the master plan. Since the location of each train plan copy on the network is recorded, broadcast messages can be sent to the centralized repository thus forcing a global update to all the copies in the network thus ensuring all plans are updated (Booch et al.).

Works Cited:

Booch, Grady et al. Object-Oriented Analysis and Design with Applications. 3rd ed. Upper Saddle River, NJ: Addison-Wesley, 2007. Print.
Fransoo, Jan Cornelis, Toni WaÌfler, and John R Wilson. Behavioral Operations in Planning and Scheduling. Heidelberg: Springer, 2011. Print.