![]() The TMS Rostering Module creates weekly assignments that maximize the number of consecutive days off. MASTER SCHEDULER MANUALThe TMS Runcutter also runs in manual and optimal modes, and produces beautifully-cut runs based on user-defined costing rules. The TMS Optimal Blocker offers trip-to-vehicle assignments that are mathematically provable as the most cost-efficient. Blocking can be performed either manually or optimally in the system. ![]() Node-to-node running, travel, and deadhead times are kept in a central location, offering ease-of-use whenever the data has to be viewed or modified. ![]() Data components, such as routes, patterns, trips, and blocks are all directly input into the system, or are generated based on input data. TMS itself follows a table-driven relational database model. When TMS moved from prototype to production at Phoenix Transit in 1993, it brought with it the first successful public transit integration of the highly-respected MapInfo for Windows and Crystal Reports products. This meant that rather than building a street map and reporting interface to the system, we would research the market and integrate those portions into the final product. We also knew that computing in the future would be based around component-built systems. With that in mind, we embarked upon the creation of the first Windows-based Public Transit Scheduling System. When TMS was conceived of, we knew that the next wave of PC-based computing would occur in a Microsoft Windows environment. Originally prototyped at the APTA Annual Convention in the fall of 1991, TMS became a production system at Phoenix Transit in 1993. This section offers the history and general description of our flagship product, The Master Scheduler. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |