DESIGN SPECIFICATION

for

AUTOMATED COMMUTER TRAIN PROJECT

CpE484 – REAL TIME SYSTEMS DESIGN

Spring 2005

Team Members:

Douglas Stull

Kelly Smith

Jeff Sumey

Bryan Walker

Preface:

The following document represents this team’s report of the software design phase of the automated commuter train project. Although we have progressed through a number of refinement iterations in the design process, the results documented herein represent but one of these iterations. This should not be interpreted as a final design but merely the most recent efforts of the team. Obviously, further iterations and completion of additional details are possible, if not for time restrictions.

One problem that was of particular hindrance to this project was the use of the AxiomSys software as the CASE tool for performing the software design and building the associated document. Although we could develop the designs in the program, we were unable to generate a report through the software.  Due to the short amount of time, we felt it was more important to emphasize on the concepts involved with design rather than learning the tricks to operating the software. Nonetheless, the goal of gaining first-hand experience in undertaking a Software Design process and the use of a CASE tool to assist in that process was accomplished.  

Our group would like to thank Dr Ammar for his assistance in the progression and development of this process. We appreciate his responding to emails quickly on weekends and appreciate his patience.  Without his guidance and direction, we would not have been able to develop our project as much as we were able to.

1. Scope
1.1. Identification
The Office of the Mayor has released a request for proposals to solve a problem in the city.  To alleviate traffic concerns, the mayor has proposed a solution that involves updating the current commuter train system.  The current system relies directly on the operator and is inefficient in recording status information such as run time and maintenance logs.  The goal of this project is to develop the software required to meet the specifications set forth by the mayor in the released memorandums.  Detailed information will be described below.
1.2. System Overview
As determined by the memorandums released by the office of the mayor, an automated commuter train system is requested. This train system shall be powered by a third rail, inaccessible by the public.  The train will be independently fully automated, except in the case of an emergency override, where in the onboard operator will resume control.  The automated trains will have control of system acceleration and deceleration, door, climate and lighting control, passenger announcements, braking and stopping patterns. The train will have four braking systems.  The braking systems will be used for general speed regulation, stopping the train, emergency braking, and safety brakes. Doors will be controlled based on information on the itinerary.  Left and right controls will be activated based on the location of the stop.

The train will run based on an itinerary sent from the central computer.  The central computer will also monitor all trains positions on the track.  Information regarding obstacles in a train’s path will be sent from the central computer. The central computer can also change the itinerary schedule of a train at ay time via the communication network (third rail).  

The train will record information including start and stop locations and times and will convey this to the maintenance database. This maintenance database will also maintain records on the trains, communication hardware, and network components as well as managing a store of service and repair history. 

The train will operate in three modes, as specified by the itinerary.  The modes are based on route and time of day.  Normal mode allows the train to stop at every location. Express mode allows the train to go directly to the specified stop with out stopping at the terminals in between. Request–Only mode requires notification by an onboard or on platform passenger to alert the train of a requested stop.

The system, as defined in the memorandums via the Office of the Mayor, requires many components to operate correctly.  The scope of this project involves designing and developing the on-train portion of the system.  This view will be reflected in all of the design documentation below.

1.3. Document Overview
This document contains the structured design of the on train control system as developed by referencing the analysis documents developed in accordance to the provided system requirements released by the Office of the Mayor.  Included structured diagrams provide detailed descriptions of the design process intended to be implemented.  The high level diagrams will occur first, illustrating the basic system structure overview.  The document will then show more specific, detailed low level diagrams to show the more specific detailed design processes, data and control flows.
2. Referenced Documents
The following documents of the exact issue shown form a part of this specification to the extent specified herein. In the event of conflict between the documents referenced herein and the contents of this specification, the contents of the specification shall be considered a superseding requirement.

2.1 Government Documents
STANDARDS:

“DOD-STD-2167A”. Software Productivity Consortium. February 29, 1988. 
<http://www.software.org/quagmire/descriptions/dod-std-2167a.asp>.
“MIL-STD-498”. Software Productivity Consortium. December 5, 1994. 
<http://www.software.org/quagmire/descriptions/mil-std-498.asp>.

Copies of specifications, standards, drawings, and publications required by suppliers in connection with the specified procurement functions should be obtained from the contracting agency or as directed by the contracting officer.
2.2. Non_Government documents

The following documents of the exact issue shown form a part of this specification to the extent specified herein. In the event of conflict between the documents referenced herein and the contents of this specification, the contents of this specification shall be considered a superseding requirement.

OTHER PUBLICATIONS:

Ammar, Hany and Lateef. Real Time Software Engineering with ICASE. January 
21, 1997. < http://www.csee.wvu.edu/~ammar/>.
Memorandum: “Proposed Automated Commuter Train”. Office of the Mayor. 
October 1, 1999.
Memorandum: “Off-Train Systems for Proposed Automated Commuter Train”. 
City Planning Department. October 5, 1999.
Memorandum: “Local, Express, and Request-Only Modes for Proposed 
Automated Commuter Train”. City Planning Department. October 7, 
1999.

3. CSCI-wide design decisions
This document includes the first steps taken in the development t of the design of the architecture. This “physical model” depicts the software elements and data structures.  It depicts the coupling between the software elements, based on the data and control flows.
3.1. Special Consideration for Safety

Considerations have been taken in this design to ensure the safety of the passengers and operators of the Automated Train System.  Special operations have been included to ensure braking systems are operating properly and with in regulations.  Maintenance systems will monitor and log information on each individual train to ensure each train is operating at the highest level of safety. Also incorporated in the design is the ability of an operator to take control of the system and control the system via an operator override.  This feature allows for safer operation controlled by a person on board the train who has been trained in the procedures for safely controlling the machine.
4. CSCI Architectural Design

This section includes decisions and diagrams about the specific design criteria not addressed in the top level architecture diagram. All decisions made were made based on the CSCI requirements as stated by the Office of the Mayor and interpreted in the Analysis documents, submitted to the Office of the Mayor on March 25, 2005.

5. CSCI Detailed Design

This section states the purpose of each software unit and identifies the requirements and decisions allocated to it.

5.1. Components
5.1.1. Control Train

Description
This function checks for the operator override. This information is transferred to the control motion and control doors modules. 
5.1.1.1. Description

Inputs:  Operator Override, Train Motion Status
Outputs:  Control of doors to Control Doors Function, Control of motion to Control Motion Function

5.1.1.1.1. Control Motion

Description
This command checks the motion commands and determines whether to start, stop, or regulate the speed of the train.
5.1.1.1.1.1. Description

Inputs:  Location, Obstacle, and Itinerary 
Outputs:  Control Speed, Motion Commands

5.1.1.1.2. Control Doors

Description
This command checks the status of the doors.  It ensures that the train is not moving while the doors are in the open position. It also refers to the itinerary on information regarding side of stop and length of open doors.
5.1.1.1.2.1. Description

Inputs:  Location, Obstruction in doorway, next stop request, and Itinerary 
Outputs:  Control Door Open and Close
5.1.2. Monitor Scheduler

Description
This command monitors the schedule provided in the itinerary.  It controls the PA message to the passengers.  This function produces the modes for which the train will operate in. 
5.1.2.1. Description

Inputs:  Itinerary Date
Outputs:  PA Commands and Displays

6. Requirements Trace-ability

The documentation below details the location and fulfillment of the specified by the Office of the Mayor and the City Planning Department.  It is listed, by requirement, as notated in the Document Memorandums from the offices above, released through October 7, 1999. 

6.1. This requirement involves the power to the train system.  This requirement involves the planning of the hardware aspect of the system and is therefore not applicable in our software process. Our systems will be able to accept the binary input control signals sent from this hardware system. 

6.2. This requirement specifies that the system must be an onboard control system.  The software the team has developed was built to run on-train.  This can be observed in the Operator Interface Module.

6.3. This requirement specifies that the each train runs based on the on-board control system. The software the team has developed was built to run on-train.  This can be observed in the Control Train Module.

6.4. This requirement specifies the on-board control systems accessible by the train. These systems are found on Control Train Module.

6.4.1. This requirement defines the braking systems of the on-train system.  The detailed description of the brake controller can be found in Control Motion, under the heading maintaining and adjusting speed.

6.4.2. The on-train control system addresses the issue of door operation in The module control doors.
 
6.5. Communication with the Maintenance Computer System is not addressed in this module. Due to the limited time allotted for work in this project, the group focused their efforts on functionality of the on-train devices; communication will be dealt with in further iterations of the design phase.

6.6. Communication with the Maintenance Computer System is not addressed in this module. Due to the limited time allotted for work in this project, the group focused their efforts on functionality of the on-train devices; communication will be dealt with in further iterations of the design phase.
.

6.7. This requirement was amended by further requirements released by the CCP.

6.7.1. Communication with the Central Computer is not addressed in this module. Due to the limited time allotted for work in this project, the group focused their efforts on functionality of the on-train devices; communication will be dealt with in further iterations of the design phase.
6.7.2. 	This requirement is not a software element.  Refer to the associated HWCI (HardWare Configuration Item) for more information on this requirement.  The HWCI is not in the scope of the project developed by this team.

6.7.3. Communication with the Central Computer is not addressed in this module. Due to the limited time allotted for work in this project, the group focused their efforts on functionality of the on-train devices; communication will be dealt with in further iterations of the design phase.

6.8. The mode operation requirement can be found in the Monitor Scheduler Module.
 
6.9.  The mode operation requirement can be found in the Monitor Scheduler Module.