MetroSub Subway Information System
Chair Developers: Valter Borges, Craig Burge, Ryan Connelly, Russell LeJeune, Steven Li, Andrew Miner, and Yan Wu.
The MetroSub is a graphical subway monitoring system which will oversee all of the functions related to the everyday operationsof a large city subway system, from the end user customer purchasing a ticket to the railway engineer performing everyday maintenance on the track. The system will be comprised of four major components:
- A group of databases, which will interact with the other four clients and receive and send information about the status of the Subway system.
- A client which interacts with the end user and provides information about schedules, ticket sales, and the status of trains.
- A client which provides the station manager, conductor, sales personnel and engineers a way to view or modify any information pertaining to the Subway system.
- A client interface representing each of the trains.
At the center of all of the functions listed above is a database server, which will be responsible for handling all of the incoming information and distributing it out to the various clients. In some cases, the clients must communicate with each other, so they must be able to both send information to the server and receive and process information as well.
The main purpose of all the functionality is to allow for a more efficient and robust subway information system, which will greatly impact subway performance.
- Asynchronous Transfer Mode Connectivity (ATM) [R.Connelly]
- Central Server [R.Connelly]
- A network of database servers that will control the flow of data and direct traffic between the other databases in the network.
- Concurrency [C.Burge]
- Several parts of a system needing to act together in sharing information for the system to work.
- Data Interface (DI) [R.LeJeune]
- A relational database front end.
- Data Mining [R.LeJeune]
- To search for applicable information from amongst many different sources, usually the diversity of the sources is transparent to the user.
- Graphical User Interface (GUI) [A.Miner]
- IDE [V.Borges]
- Integrated Development Environment
- Java2 SDK [V.Borges]
- Java 2 Platform Software Development Kit
- JDBC [V.Borges]
- Java Database Connectivity
- JRE 1.2 [V.Borges]
- Java Runtime Environment 1.2
- "Just In Time" (JIT) [R.LeJeune]
- At the moment it is needed or occurs.
- JVM [V.Borges]
- Java Virtual Machine
- Kiosk [A.Miner]
- A computer access terminal, which is designed for public use.
- Lightweight Components [V.Borges]
- Components, which do not depend heavily on peer objects.
- Local Area Network (LAN) [A.Miner]
- A network, which serves to connect several machines together within a relatively small area (e.g. less than a kilometer).
- Mass Transit [R.LeJeune]
- In MetroSub's world Mass Transit is all other forms of public transportation, i.e., taxis, buses, shuttles or horse drawn carriage, etc.
- Metropolitan Area Network (MAN) [A.Miner]
- A large network which would span the distance of several kilometers. Such a network would be necessary to provide coverage for most subway systems. See also LAN.
- Network Infrastructure [R.Connelly]
- Overall scheme of distributing the movement of information through the system, i.e. ATM.
- Parallelism [C.Burge]
- Running multiple systems concurrently throughout the system to insure the information is up to date and eliminate system deadlock.
- Privilege Level Scheme [S.Li]
- Different users in the system are assigned different privilege levels according to what type of user they are and what information they need.
- RAD [V.Borges]
- Rapid Application Development
- Real Time [C.Burge]
- Happening at that moment in time
- Security Access [Y.Wu]
- User accesses to a particular function of the system base on his/her privileges.
- Swing [V.Borges]
- Successor to AWT (Abstract Windowing Toolkit)
Operating Environment [V.Borges]
The MetroSub environment will operate using Sun Microsystems JVM. We have decided to use Java 2 SDK and JRE 1.2 because of its versatility and features that will allow us to develop such a large-scale system.
The MetroSub system will be used within the subway system, at home and inside the trains. We expect such a system to handle hundreds of simultaneous users accessing different types of information stored in different databases. Users will range from expert to novice, with that in mind, we will provide easy and intuitive GUI's, which should make any user feel comfortable using the system. The variety of users will have different access levels and information organization will be catered to the different access levels.
Java is the perfect solution because it offers a simple objected-oriented development environment. In addition, it also provides Robustness, Security, Portability, Multi-threading, and ODBC capabilities, which are just a few of the more important features needed in order to accomplish our task.
The hardware environment will range from display panel and user kiosks, to regular PC's and Workstations. For the server side we will use a workstation, which can handle multiple connections and large-scale data storage.
Customers and Train Operators would use a touch sensitive screen to interact with the system. The rest of the users will use a regular mouse and keyboard.
For programming tools we will use Visual Cafˇ 3.0 by Symantec Corporation and CodeWarrior 5.0 by Metrowerks Inc. Both of these packages provide a powerful IDE and RAD assistance that will help in organization and save time by performing the redundant task that one would face using a command line environment. Visual Cafˇ and CodeWarrior are compliant with JDK 2, JRE 1.2.
The graphical user interface will be developed using the Java 2 Platform Swing Classes, which have a richer collection of user interface components, and a standard look and feel because they are lightweight components and do not use the native operating system to render the GUI components.
To connect to the variety of databases integrated into our system we will use JDBC , which is the Java 2 Platform API for database connectivity. JDBC provides database interface abstraction through the use of different layers.
User Interface [A. Miner]
The user interface is divided into one section for each user role. The user roles: customer, station manager, administrator, conductor, mechanic, and sales person each represent a different way in which the system would be used (where an individual may switch from one role to another throughout the day), and thereby also a different facet of the user interface of the system as a whole.
There are many aspects of the user interface which are required to change in accordance with a change in role: the display medium, the particular kind of information available, the detail of the information displayed, the ease of use of the interface, and the which tasks are available.
- The primary Customer interface will be in the form on information kiosks, which will be located both in the stations and on the trains. Each will employ a touch-screen for their interface, and will be otherwise completely enclosed (much like those currently found in supermarkets and department stores).
- The graphics of these terminals will be displayed with large buttons (to facilitate activation with a finger) which give the user real-time access to information required to navigate the subway system (e.g. schedules, maps, access to their own account information, etc.). This interface will automatically center the display of maps and other information pertaining to the location of the kiosk, and can identify the current location of the user on demand.
- The maps will be available at several levels, based upon a sliding scale with the user can control. This will display the user's location in terms of the current station or train, the general area (i.e. including the adjacent stations), and within the system as a whole. The maps will be displayed as color-coded lines using dots or simple icons to convey the location of various landmarks. This interface should be web-based, and therefore available from anywhere on the Internet.
- Station Manager
- The Station Manager's interface will be an application program, which can be run from a PC, attached to the system-wide MAN. This application would provide a station manager with real-timeinformation regarding the status of the system as a whole. This would include the location of trains, the status of said trains, the ability to view and make schedules, add and remove work orders and inventory, and otherwise perform the functions associated with the management of a modern subway system. This panel would offer the same ability to view the subway system as does the Customer interface, except with much greater detail.
- The Station Manager's interface would show each track, the projected number of travelers in particular areas of the system, indications of breakdowns, malfunctions, and other problems in real time. The interface will assume some level of knowledge of PC systems and typical GUI interface components (e.g. windows, icons, menus, buttons, etc.).
- The Administrator uses the system in a radically different way than any other user in that he is interested more in the operation of the computational equipment, and rather little interested in the operation of the subway equipment. This implies that the Administrator's tools will show a map of thenetwork and the locations of servers, routers, switches, etc. with regard to the locations of the other subway landmarks.
- In addition, the Administrator should be able to have access from any PC or kiosk within the system, as well as limited access to various functions over the Internet.
- The Conductor has the primary responsibility of guiding a particular train along its route, and therefore has need of a verydetailed but specialized set of information. The Conductor should have a special kiosk (hidden much like the control booth of modern subway trains) which is used to access the system. The Conductor needs to have access to information regarding the status and repair of his own train, as well as the conditions and status of the track and stations along his route.
- The Mechanic primarily has need of information regarding pending repairs and available inventory. His terminal should take the form of a hand-held, clipboard-style, and wireless computer that should have a durable keypad, which can be used for writing short reports and otherwise interfacing with the device.
- The Sales personnel will be located both in information booths in the stations, as well as in office space answering telephone calls. In either case, a typical PC with a custom application will allow them to access the Customer account information as well as maps and other services required for customer support.
Data Interfaces [R. LeJeune]
A thorough description of the inter-system and database interfaces. All database interfaces are to provide accessibility of the information to and from the server and out to the world. The data interfaces are the front ends of our mine of databases.
Interface to the Schedules database will provide scheduling information of the trains to the user interfaces and allow change/update capabilities only to the Station Master. The information received and sent by the interface are train schedules and specific route information and are stored as elements of a relational database. The nature of the interface is graphical for update capabilities by the station master and invisible to the user interfaces that access the information through a kiosk.
Interface to the Inventory database provides all available stock information, e.g., extra kiosks, rail parts, MetroCard supplies. The interface allows access to the Conductor, Administrator, Mechanic, and Station Master interfaces in order for inventory to be properly distributed. A graphical inventory control interface will allow updates to the database when items are ordered and usedand store the information as elements of the database.
Interface to the Billing database provides information about the customer accounts and sales. The Billing interface allows access by the Sales and Customer interfaces in order for users to address account information and provide ticket transactions. The interface updates user accounts, process ticket transactions andsupplies statistics of MetroSub customer traffic to be stored in the statistics database.
Interface to the Status database provides information of the current, real-time status of trains, stations and other locations. All user interfaces require access through the Status interface in order to read real time information about train/station and kiosk availability and allow "just in time" updates to the Status database by station masters and conductors.
Interface to the Maintenance database provides the work orders currently in production within the subway system. The interface allows recording updates, additions and completions to the Maintenance database via document submission.
Interface to the Statistics database supplies demographic information, which is stored as separate elements and supplied by the Billing, Inventory, Status and Security databases. The interface allows an automated pull from each related databases to update the Statistics database. Likewise the interface allows the user interfaces to query the database for data mining.
Interface to the Topology database provides the actual vector data, which is used to generate the graphical maps used by the system. The graphics interface accesses the Topology interface in order to provide maps and directions to the various users, i.e. track maps to the Conductor and station locations to the Customer.
Interface to the external Credit Card database provides access to the outside world and allows customers to use their credit cards as a form of payment. The interface doesn't have direct control over the external database, it only submits billing forms andrequests account verification through the Sales interface.
Interface to an external Security database allows the system to communicate emergency information, update security issues and provide a 911 service. The interface allows all user interfaces to send/receive instant communications to Security, Fire and Ambulance emergency databases located within the MetroSub Stations and outside the subway.
Interface to an external Mass Transit database allows a connection to other forms of transportation, i.e., taxis, buses and shuttles. The interface allows queries from the user interface to Transit databases for locating scheduling and requesting alternative transportation.
Information [S. Li]
People use subways as a transportation tool to get from one place to another. A subway system is to provide people with conveniencein their traveling. Therefore, useful traveling information should be represented to make traveling quick and easy. Although it is essential to provide information externally to our customer, it is also important for the subway system to maintain a good internal information system.
An information system can be implemented upon a centralized database to allow users to access the information quickly and effectively. There are many different roles of the user each needing to access the database system, and each category of user accesses and uses the information in a different way. Thus, the centralized database must be broken down into different smaller units to distribute among the various users.
As specified in the database section of the spec, we have the following classes of databases: schedule, billing, inventory, status, topology, and statistics. Their usage are as following:
- Schedule database provides customers with train schedules throughweb sites, display units, and printed materials.
- Billing database holds sale information, customers account records of customers who carry metro-cards. The billing database can also be used to measure the performance of the system
- Inventory database holds information about the quantity and location of various equipment, parts and supplies which is vital to the technical employee and the station managers in order for them to manage the physical conditions of the system.
- Status database provides real time information to the customer about locations and conditions of the current active trains, and also provides information to the internal employees for better efficient operation as a whole.
- Topology database provides graphic maps of all track lines, and it interacts with Status database to display accurate location and conditions of operating trains in order for the customer to have a clear view of the real time schedule.
- Statistics database is a dependent database that pulls information from all other databases in the system for further analysis, i.e. user traffic, ticket sales, emergency issues per day/week/month. The statistic database supplies the information, which will determine where future improvements will be needed to maximize the overall efficiency.
Users access to the information in the database can be based on a privilege level scheme. Privilege level access means different users in the system have different privilege levels assigned according to what type of users they are. The customer may only be able to view the scheduling information while the sales representative can access all the billing information and any other information that they need for the accounting operation. For a user,the higher privilege level he/she is assigned the more information he/she can access. The highest privilege level is assigned to the station managers because such information are need for the overall management of the MetroSub system as a whole.
Performance [R. Connelly]
In the MetroSub system, the largest performance concern comes with the large amounts of data that will need to interact with all of the components of the system. Each of the interfaces with the system will have some database connectivity behind it, so the speed in which the data can be sent back and forth is very important. Since the MetroSub system is going to be used in a metropolitan area, the number of users using the subway are very high (hundreds in a station at a time). The system will span many different stations in a city, the actual number of customers using the information kiosks at one time could also number in the hundreds concurrently.
Each information kiosk will be able to have several customers accessing ticket information, schedules, train locations, etc. This means the amount of data from just the information kiosks is extremely high. The system will have to have an appropriate network infrastructure in place (such as an ATM network) to handle this data. While the data in the user kiosks are not the highest priority, the train location must be updated rather quickly to make the maps worthwhile to customers. The other information can have a slight delay, though anything longer than a few seconds will be annoying, albeit not critical.
One critical area is the emergency functions. If a user recognizes an emergency and pushes a button to signal something has happened, that has to process immediately for it to be effective in controlling potential disasters.
The other aspects of the system (Billing, Station Master, Trains, and Admin) can also tolerate small delays (in most cases). The credit card companies' databases and time of return will bound the billing system. The Station Master's updates of the schedules don't have to be real time either. However, in the different trains, the component that responds to the train's sensor do have to react quickly and update the databases quickly in order to avoid a disaster.
The interfaces themselves, which will be implemented in Java, will have to run fast enough to be able to get the data that it needs. These interfaces should be active at all times but the small amounts of time that they are unavailable will not cause a catastrophic failure. The system itself, which is mostly the database server, must be active unconditionally twenty four hours a day, seven days a week. It will have to have a secure backup disaster plan, which must be switched on automatically if the primary server goes down. Our database itself must be capable of having several hundred active sessions at once. Most likely, our "central" server will be a network of database servers that will control the flow of data for each station and direct traffic between the other databases in the network.
Parallelism [C. Burge]
Several of the databases are going to have to run parallel for this system to work. Without certain databases running in parallel to the clients, information would be lost, or would be received to late for anything to be done about it. Running the information for these databases in parallel to the client is more efficient and safer than running all the databases on a sequential cycle.
The real time information database is run in parallel with topology database and the billing database. For a few reasons; the topology database holds information regarding the track that a train runs on, stations that are open for business, and other important current graphics information. If a station needs to be shut down, then along with this information from the real time database, information can be relayed to the maps so that people won't attempt to use those stations and the trains can avoid stopping at them. If there is a problem on one of the tracks, then the conductor on the train would be notified even if he already opened one of the maps. Situations such as these, which arise spontaneously, need to be changed as soon as they occur.
The billing database also needs to be notified concurrently so that it will not allow people to buy tickets to problem areas. Otherwise people may continue to buy tickets for a rout which has been closed down. The billing database also needs to run in parallel with the outside credit database so credit card confirmation can be checked while the purchase is approved.
The security database is run in parallel with all of the systems. Security is omnipresent so that any major security problems in any of the stations will automatically notify any database so all users will be advised of the emergency. Automatic notification is necessary so that if, for example, a fire broke out in station one, all trains, administrators and the general public will be notified without them having to physically check for that information. Concurrent notification allows all users to take appropriate action as to avoid that area until the problem is solved.
Concurrent Engineering [C. Burge]
Several parts of this system need to act together in sharing information for the system to work. The reason for concurrency is that some parts of the system work as a stand alone client, which otherwise would cause them to miss vital information and inevitably bring the entire system down as a whole.
In this section, the vital links between the system components will be explained. The user kiosk is a part of the system in which the general public has access to the information. Kiosks are where the public is allowed to check for directions, schedules, and make credit operations to buy tickets, find means of transportation when leaving the trains, and get general and emergency help. This client will have to interact with several of the internal databases, and a few external databases in order to provide the proper information. The kiosks will need to have access to the scheduling, billing, real time status of events, topology, security, and mass transit databases.
For any one of the options that the user may select, the real time status database will be accessed at the same time to notify the user of any current changes to the information that they are trying to access. Additionally, when the user makes a credit transaction, the internal billing database is notified along with the external credit database to check to see whether the card that the user is using is still in good standing. This needs to occur before the billing database accepts the information and the client gives the person a ticket meaning both operations need to occur simultaneously.
The security on the client relies on an outside server, which activates the local public safety departments. The subway system does not have its own services therefore relies on the local authorities to be utilized, in which case, the security option on the kiosk will trigger the city's dispatching server, either within the MetroSub stations or outside in the city.
Other clients in the system, which are directed towards administrative purposes have several different access levels, which will be discussed later. However, the access levels do not change the information that needs to be shared among the databases.
The maintenance, inventory, and statistics databases can access independently. These information databases do not need to change concurrently. If part of the subway system needs to be fixed, for example, it is added to the maintenance database so that the mechanics can see what their next list of duties will include. The real time statistics database will then read from the maintenance database to update what it knows as faulty areas in the system. These databases do not, however, need to share information in order to work properly.
The topology database will need to access the real time database before any of the information contained can be presented. The topology database will allow the customers to view what stations may have closed recently or allow conductors to be able to access whether something wrong with their track. Information that may change at any time is included here so this database must be constantly updated in respect to the real-time information database.
Security [Y. Wu]
The main purpose of the security plan for the MetroSub system is to prevent any unauthorized personnel gaining access to any restricted databases, and to ensure the authorized personnel are not prohibited from accessing their required information. Users should not be viewing the information on any database that should not be seen. All of the potential users of this metro system are organized into six types of users; administrator, station master/managers, conductors, mechanics, sales representatives and customers. Each user performs a different role and is responsible for using different parts of this metro system.
User Security Roles
- System maintenance, computer networking and responsible for any technical failure/upgrade.
- Station Master/Managers
- In charge of a particular station, reports any problems that might occur at that station and maintains day to day operations.
- Responsible to a particular train, and reports the status of the train and all other problems (out of stock, parts broken).
- Responsible for any mechanic breakdown (fixing track, escalators, etc) as well as adding/updating inventory.
- Sales Representatives
- Taking ticket orders, providing scheduling, billing (collecting payment for tokens, debit card or credit card) and assist customers with general help (direct customers to places if necessary).
- Purchasing tokens/tickets using debit/temp card (putting credits into a temp card) or monthly billing with credit card, using navigational functions (maps to find train locations, or to exits).
All users have different access to several different databases. However their accessibility to some of the databases maybe limited. For instance, a customer's access to the Billing database is limited only to his account information. He/she does not have any access to view or change another customer's billing information. A customer is able to view the MetroSub schedule, however he/she does not have the permission to change any information on this schedule. Similarly, each conductor on a particular train has different access privileges to different databases. He can change or update the status and maintenance databases according to his train, but does not have any access to the status and maintenance databases of another train.
A detailed description of each user role's accessibility to different databases is listed in the table shown below.
|----||No accessibility whatsoever|
|RW||Read and Write only|
|LR||Limited read access to only a portion of the database|
|LRW||Limited read and writes to only a portion of the database|