Docstoc

train traffic control system

Document Sample
train traffic control system Powered By Docstoc
					    Train Traffic Control System
            Course 95.590
          Requirement Report

Date Updated: 10 November, 2011

 Prepared By: Son Huynh
              Simon Kaegi
              Jon McPhail
95.590 Train Traffic Control System                                                                                   Version 0.4
Requirement Summary Report


Table of Contents

DESIGN TEAM MEMBERS ............................................................................................ 1

INTRODUCTION ............................................................................................................. 1
  BACKGROUND ................................................................................................................ 1
  SYSTEM OBJECTIVE ........................................................................................................ 1
  SYSTEM SCOPE .............................................................................................................. 2
  STRUCTURE ................................................................................................................... 2
REQUIREMENTS SUMMARY ........................................................................................ 5
  REVISED REQUIREMENTS ................................................................................................ 5
  REQUIREMENT CATALOGUE ............................................................................................. 6
SCENARIO ANALYSIS ................................................................................................ 10
  CONTEXT ..................................................................................................................... 11
  SCENARIO TEXT DESCRIPTIONS ..................................................................................... 12
REFERENCES .............................................................................................................. 20

Table of Figures

Figure 1 - Current System Scope .................................................................................... 1
Figure 2 - Complete Use Case Diagram ....................................................................... 10
Figure 3 - Dividing Physical Track into Subdivisions / Blocks........................................ 13
Figure 4 - Change Entry Signal ..................................................................................... 15

List of Tables

Table 1 – Guide To Requirements Table ........................................................................ 3
Table 2 - Scenario Text Description Template ................................................................ 3
Table 3 - List of Assumptions .......................................................................................... 4
Table 4 - List of Revised Requirements .......................................................................... 5
Table 5 - Requirements Catalogue Table........................................................................ 6




10 November, 2011                                                                                                      i
95.590 Train Traffic Control System                                                                        Version 0.4
Requirement Summary Report


95.590 Train Traffic Control System Requirements Report

Design Team Members
            Son Huynh                     e-mail: son.huynh@statcan.ca
            Simon Kaegi                   e-mail: skaegi@sympatico.ca
            Jon McPhail                   e-mail: mcphail@mondenet.com

Introduction
This requirement summary represents the requirements for the Train Traffic Control
System (TTCS) Project updated as of 10 November,2011.

Background
This requirement summary is an integral part of the Real Time Traceable Object
Oriented Process (RT-TROOP) [1] for software design followed to meet the stated
objective of the system. For the duration of the project this report will represent the
Design Team’s understanding of assigned requirements.

System Objective
The stated objective of this system is to provide a Train controller, also known as
dispatcher, the capability to remotely control train traffic on an assigned subdivision.



                                                     TRAIN CONTROLER




             PRESENTATION                   Train Controller User Interface




               DOM AIN
                LOGIC                         Train Traffic Control System




               PHYSICAL
             ENVIRONM ENT

                             Se nsor        Switch        inside curre nt scope   Outside curre nt scope



                                       Figure 1 - Current System Scope




10 November, 2011                                                                                                   1
95.590 Train Traffic Control System                                                   Version 0.4
Requirement Summary Report


System Scope
Figure 1 provides a representative view of the Train Traffic Control System (TTCS). In
time the end capability of the TTCS will include the ability to remotely control trains
within allocated track subdivisions. However, based on the complexity of providing a
complete capability, this initial project will limit the system scope to the Train controller’s
interaction with the TTCS in particular related to the control of signal and switch
devices.
As noted in the Figure 1 the input from sensors located on the track along with any
communication between the train and the TTCS is currently considered outside the
scope of this system. In essence, the system will focus on taking the inputs from a train
controller, through a Train Controller User Interface, validate the input and permit the
execution of control instructions to physical track switches.

The fact that the physical train is considered outside the scope of this initial project does
not imply that the train can be ignored in the TTCS. With this in mind the analysis and
design of the system will consider the context of train movement through the physical
environment.


               …this initial project will limit the system scope to the
               train controller’s interaction with the Train Traffic
               Control System in particular related to the control of
               signal and switch devices

Structure
This report is composed of three parts:

   Introduction. This introduction to the document provides a high level perspective
    concerning the system, along with a complete summary of assumptions made in
    designing the initial project.

   Requirements Summary. This section provides a complete list of the system
    requirements considered. The section is introduced, with an outline of requirement
    amendments, since the previous release of the summary other than the initial and
    final submissions.

   Scenario Analysis. Consistent with RT-TROOP, an initial analysis of stated
    requirements is provided in the form of Scenario Text Descriptions / Use Cases. The
    section is briefly introduced by an outline of the Design Team’s understanding of the
    overall context within which the system is used.




10 November, 2011                                                                              2
         95.590 Train Traffic Control System                                                                                  Version 0.4
         Requirement Summary Report


         A standard table format, as depicted in Table 1, will be used to list the assumptions and
         requirements identified that are relevant to this project. If an assumption is accepted as
         a requirement by the client then its assumption id will be abandoned and a new
         requirement id appropriately assigned.
                                               Table 1 – Guide To Requirements Table
    ID               Title                                              Description                                     Source Reference
A – Assumption.
F – Functional Requirement.
NF - Non Functional Requirement
id number as   Concise, Descriptive Title   A statement of the description as stated by the source and agreed to by   Reference of where and
specified                                   the client. (professor)                                                   when      the    requirement
below                                                                                                                 originated.
001-A          Assumptions                  The 000 – 099 series represent the assumptions made during the course     RequirementStatement [26
                                            of this project.                                                          Jan, 2000]
100-F[NF]      System                       The 100 – 199 series represent high level system requirements of either   InClass [25 Jan, 2000]
                                            the functional [F] or non functional variety[NF]
200-F[NF]      Safety Rules                 The 200-299 series represent requirements that can be classified to       Group discussion [24 Jan
                                            specify safety rules.                                                     2000]
300-F[NF]      Subdivision                  The 300-399 series represent requirements that are related to the
                                            specification of the subdivision.
400-F[NF]      Block                        The 400-499 series represent requirements that are related to the
                                            specification of the block.
500-F[NF]      Signal                       The 500-599 series represent requirements that are related to the
                                            specification of the signal.
600-F[NF]      Switch                       The 600-699 series represent requirements that are related to the
                                            specification of the switch.
900-F[NF]      Miscellaneous                The 600-699 series represent requirements that are considered
                                            miscellaneous and do not fit into the other classifications.


         In order to capture information related to Scenario Text Descriptions as format
         consistent with the RT-TROOP method is used. A sample of the standard table is
         provided in Table 2. An explanation of Scenario Text Descriptions is considered outside
         the scope of this report.
                                            Table 2 - Scenario Text Description Template
 STD Identifier: USE CASE NAME HERE                                                                                           Requirement
                                                                                                                               Reference
 Description: Enter a brief textual description of the overall objective of the scenario.
 External Actors: Enter the set of external actors that participate in the scenario.
 Precondition: Enter the precondition that must be satisfied in order to enable the execution of the
 scenario.
 Triggering Event: Enter the triggering event description here.
 Sequence of Responsibilities:
 1. Enter responsibility one here.
 2. Enter responsibility two here
 3. And so on

 Postcondition: Enter the postcondition that must evaluate to true after the execution of the
 scenario.
 Resulting Event: Enter a set of possible resulting events here.
 Alternatives: (optional) enter a set of alternative scenarios.
 Nonfunctional Requirements: Enter a set of nonfunctional requirements that apply to the
 scenario (optional)
 Comments: Enter a comment section that may be used by designers as a free format text window
 to specify different issues related to the scenario.




         10 November, 2011                                                                                                              3
        95.590 Train Traffic Control System                                                                                        Version 0.4
        Requirement Summary Report


        Assumptions
        The assumptions listed in

        Table 3, represent those made by the design team, appropriately referenced, or
        identified by the client. In certain cases, there may some assumptions that will directly
        impact the design developed in this initial project. In these cases, a specific request will
        be addressed to the client to transform an assumption into a requirement. Based on
        subsequent authorization, the necessary transition actions proposed in the Structure
        section of this report will be applied.

                                                      Table 3 - List of Assumptions
  ID                 Title                                               Description                                         Source Reference
001-A    Instantaneous Communication       Communication is instantaneous, failure free and no corruption of               Description of TTCS [26
                                           information.                                                                    Jan, 2000]
002-A    Trains Obey Signals               Trains always obey the traffic signals and DOBs                                 Description of TTCS [26
                                                                                                                           Jan, 2000]
003-A    No Power Failure                  There is no power failure                                                       Description of TTCS [26 Jan
                                                                                                                           2000]
004-A    Single Tracked Subdivision        The Subdivision is single-tracked one                                           Description of TTCS [26 Jan
                                                                                                                           2000]
005-A    Total Control of Train Not        The Train controller / system does not have total control of the Train.         In Class [ 1 Feb 2000]
         Required
006-A    Track Layout Flexibility Not      It is assumed that the user interface is limited to work with a static one-     In Class [ 8 Feb, 2000]
         Required                          track layout. That is, it is not required to provide a track layout user
                                           interface that is re-configurable.
007-A    Train Controller is not allowed   It is assumed that the train controller cannot impose speed restrictions        In Class [8 Feb, 2000]
         to impose speed restrictions      for a block.
         on blocks.
008-A    Physical Signals                  It is assumed that physical signaling is to be handled inside the               In Class [25 Jan 2000]
                                           locomotive of the train (as in the case of TGV locomotives). This
                                           assumption coupled with the fact that direct control of the train will not be
                                           considered during this project, implies that controlling of physical signals
                                           is outside the scope of this project.




        10 November, 2011                                                                                                                     4
        95.590 Train Traffic Control System                                                                 Version 0.4
        Requirement Summary Report




        Requirements Summary
        This section is divided into two parts, including:

           Revised Requirements. A summary of changes to requirements since the previous
            reporting period is presented; and

           Requirements Catalogue. A complete list of the up-to-date requirements is
            provided.

        Revised Requirements
        Table 4 provides an update of those requirements that have been amended, or added in
        subsequent releases to this summary. In the case of amended requirements the change
        will be highlighted. This section will not appear in the final version.
                                         Table 4 - List of Revised Requirements
 ID              Title                                      Description                                     Source
                                                                                                           Reference
901-F    Remote Train Control    As Stated: This system remotely controls trains. This                 Description of TTCS
                                                                                                       [26 Jan 2000]
                                 requirement is considered outside the scope of the initial project.
                                                                                                       In Class [01 Feb 2000]




        10 November, 2011                                                                                             5
         95.590 Train Traffic Control System                                                                        Version 0.4
         Requirement Summary Report




         Requirement Catalogue
         Table 5 provides the complete list of functional and nonfunctional requirements
         identified as of the release of this report.

                                             Table 5 - Requirements Catalogue Table
  ID                Title                                         Description                                      Source
                                                                                                                  Reference
100-F      System
           Requirements
101-F      System Objective            As Stated: Must develop a system that allows a train controller        Description of TTCS
                                                                                                              [26 Jan 2000]
                                       to remotely control train traffic control on subdivision. Build the
                                       basic infrastructure for train traffic control.
                                       Interpretation: The system will provide the basic infrastructure
                                       for train traffic control. It must allow a train controller to
                                       remotely control train traffic control on an assigned subdivision.
102-F      Interaction with            As Stated: A train controller may control more than one                Description of TTCS
                                                                                                              [26 Jan 2000]
           Train Controller.           subdivision at a given time. A train controller controls all signals
                                       and switches located in the subdivision. The train controller can
                                       move a train from one track to another by turning a switch. (see
                                       also F03, F13)
102-F      System                      As Stated: Train controller, blocks (block entry and exit points),     Description of TTCS
                                                                                                              [26 Jan 2000]
           Components                  and switches.
103-F      Train Definition            As Stated: For purposes of project the length of a train is            In Class [25 Jan 2000]
                                       limited to the locomotive.
104-NF     Train Control               As Stated: Build the Train controller Interface. Specify               Description of TTCS
                                                                                                              [26 Jan 2000]
           Interface                   Subdivision Configuration objects associated with a specific
                                       Subdivision Graphical User Interface.
                                       Interpretation: In addition to the system, a graphical user
                                       interface (GUI) needs to be built to let the controller interact
                                       with the system. The GUI shall provide the following
                                       information:
                                       - Block number wit indication of current occupying train.
                                       - Status of all signals.
                                       - Current switch orientation.
                                       - Direction of traffic flow through a block.
                                       - Current speed limit of the block.
105-NF     System           Domain     As Stated: Specify Subdivision Configuration objects                   Description of TTCS
                                                                                                              [26 Jan 2000]
           Classes,           static   associated with a specific Subdivision Graphical User Interface.
           structure            and    Specify block composition and block characteristics.
           behaviour.                  Interpretation: The domain classes of the Train Traffic Control
                                       System must be able to take the inputs and provide outputs to
                                       the developed GUI. These domain classes must appropriately
                                       specify block composition and corresponding characteristics.
106-NF     Initial Iteration –         Specify the system architecture.                                       Description of TTCS
                                                                                                              [26 Jan 2000]
           System Architecture
107-NF     Programming                 The user interface is to be implemented in Java, with the              In Class [25 Jan 2000]
           Language                    system implemented in C++.
108-NF     Modeling Tool               The software design shall be modeled using ObjectTime                  In Class [25 Jan 2000]
109-NF     System Quality              The system must have the following qualities:                          In Class [25 Jan 2000]
                                        Reliability: Controller must be able to rely on the system to
                                           successfully control the signal and switches
                                        Timeliness: The system must act on the commands in an



         10 November, 2011                                                                                                   6
         95.590 Train Traffic Control System                                                                     Version 0.4
         Requirement Summary Report


  ID                Title                                       Description                                     Source
                                                                                                               Reference
                                          acceptable time period.
                                         Delivery timeliness: The system must be delivered on the
                                          specified date.
                                       Robustness: The system must behave reasonably even
                                          under circumstances that were not anticipated in the
                                          requirement specification.
                                       Correctness: The system must response correctly the
                                          commands received from the controller, any invalid or
                                          undetermined command must be refused
110-NF     Requirement                Group requirement summaries are to be provided to the client         In Class [25 Jan 2000]
           Summary                    (professor) using MS Word.
111-NF     Platform                   The implementation must be written to run in the current PC          In Class [1 Feb 2000]
                                      environment (Windows NT).
200-F      Safety Rules
201-F      Validate Input             As Stated: This system validates the input (signal request or        Description of TTCS
                                                                                                           [26 Jan 2000]
                                      switch movement).
                                      Interpretation: The system must validate all the input from the
                                      train controller and act in a correct and robust fashion. If an
                                      invalid input is detected, the train controller must be notified
                                      with a clear and understandable message and the requested
                                      action will not be executed in this case. An uncertain command
                                      should be treated as an invalid command.
202-F      Follow Safety Rules        As Stated: This system must ensure safety rules under all            Description of TTCS
                                                                                                           [26 Jan 2000]
                                      circumstances. Train movement must always be protected by
                                      the traffic control system. The system to be developed must
                                      ensure all train movement safety rules under all circumstances.
                                      (see also F13, F14)
203-F      Green Before Red           The entry signal of a neighboring block cannot be Green if the       In Class [8 Feb 2000]
           not allowed                block in questions entry block is Red.
204-F      Safe Breaking Block        For the purposes of this project the blocks that must be placed      In Class [8 Feb 2000]
           Distance                   under caution in order to permit safe braking is 2. The number
                                      of blocks that are required for safe breaking is to be stored in a
                                      global value in order to accommodate for future changes. This
                                      safe breaking distance is normally manifested in the user
                                      interface by yellow signals before the red signal.
205-F      Signal Cancel time-        In the case that a train controller cancels a signal action, there   In Class [8 Feb 2000]
           out                        must be a time out period before resetting the signals.
                                      (Flashing red is used to represent a cancelled signal). Once the
                                      time-out period has lapsed the train controller can request
                                      another change.
300-F      Subdivision
           Requirements
301-F      Definition                 As Stated: Trains run on subdivisions, which represent a             Description of TTCS
                                                                                                           [26 Jan 2000]
                                      portion of the territory, covered by a railway company. A single
                                      subdivision is divided into blocks. Each subdivision is controlled
                                      by a train controller. The allocation of subdivisions to train
                                      controllers may dynamically change over time.
302-F      Train Subdivision          As Stated: A train can only occupy the main track of a               Description of TTCS
                                                                                                           [26 Jan 2000]
           Entry                      subdivision after receiving an initial clearance for this
                                      subdivision. This initial clearance is what creates the train.
303-F      Train Traffic Flow         As Stated: The train traffic flow is bi-directional.                 In Class [25 Jan 2000]
304-F      Train Existence            As Stated: A train only exists on one subdivision at a time.         In Class [25 Jan 2000]
                                      (see also F13)



         10 November, 2011                                                                                                7
         95.590 Train Traffic Control System                                                                      Version 0.4
         Requirement Summary Report


  ID                Title                                       Description                                      Source
                                                                                                                Reference
305-F      Subdivision                As Stated: As a train is created on a subdivision it must be          In Class [25 Jan 2000]
           Transition                 deleted from the subdivision it is leaving. (see also F13, F17)
306-F      Subdivision Tracks         Each sub-division has two tracks, a North and South track.            In Class[8 Feb2000]
400-F      Block
           Requirements
401-F      Definition                 As Stated: A block is a piece of track guarded by two traffic         Description of TTCS
                                                                                                            [26 Jan 2000]
                                      signals, one at each end of the block. Each block is defined in
                                      terms of a set of parameters such as length, location, maximum
                                      speed, current speed restriction, etc.
402-F      Block Signals              As Stated: A block is guarded by two sets of signals. Each set        In Class [25 Jan 2000]
                                      represents a particular direction of traffic flow. Within each set
                                      there are two signals, an entry signal and an exit signal.
403-F      Block Length               As Stated: A block is of variable length dependent on a               In Class [ 25 Jan 2000]
                                      number of characteristics. In France a typical length is 1500 m.
404-F      Block Neighbors            As Stated: A block must know its neighboring blocks and/or            In Class [25 Jan 2000]
                                      switches.
405-F      Block Entry                As Stated: A train can only enter a block if the train controller     Description of TTCS
                                                                                                            [26 Jan 2000]
                                      explicitly gives the train the permission (green or yellow signal).
                                      (see also F13)
                                      Interpretation: The system must ensure a train is allowed to
                                      enter a block only if the controller explicitly gives a correct
                                      permission (green or yellow) and the permission does not
                                      violate safety rules.
406-F      Block Entry                The exit signal of one block acts as the permission for a train to    In Class [25 Jan 2000]
           Permission                 enter the following block.
407-F      Block Occupation           Under normal circumstances, only one train can occupy a block         Description of TTCS
                                                                                                            [26 Jan 2000]
                                      at any given time.
408-F      Block Boundary             The east boundary of a block is marked on the user interface          In Class [8 Feb 2000]
           Demarcation                by the distance of the block boundary from the western
                                      boundary of the subdivision
409-F      Block Direction      of    There are two directions of travel through a block, eastbound         In Class [8 Feb 2000]
           Travel                     and westbound.

500-F      Signal
           Requirements
501-F      Signal Input and           As Stated: This system takes signaling commands from train            Description of TTCS
                                                                                                            [26 Jan 2000]
           Control                    controllers. This system controls signaling.
                                      Interpretation: The system must be able to receive correctly
                                      signal commands from the train controller and translate these
                                      commands correctly in order to control signal devices
502-F      Signal Turning             A signal can only turn green after verifying that all safety rules    Description of TTCS
                                                                                                            [26 Jan 2000]
           Green                      are respected.
503-NF     Signal Display             A circle represents the entry signal for a block with a tail          In Class [ 8 Feb 2000]
                                      oriented in the direction of inbound traffic. Each block has two
                                      signals, one for each direction of travel (eastbound /
                                      westbound)
504-NF     Signal Colors              All three possible colors of a signal are to be displayed in the      In Class [ 8 Feb 2000]
                                      train controller user interface.
505-F      Signal Options             A dispatcher can only change the signal from green to red or          In Class [ 8 Feb 2000]
                                      red to green. The system is responsible for changing signals to
                                      yellow.

600-F      Switch



         10 November, 2011                                                                                                  8
        95.590 Train Traffic Control System                                                                  Version 0.4
        Requirement Summary Report


  ID               Title                                      Description                                    Source
                                                                                                            Reference
          Requirements
601-F     Switch Commands            As Stated: This system takes switching commands from train         Description of TTCS
                                                                                                        [26 Jan 2000]
                                     controllers. This system switches control devices.
                                     Interpretation: The system must be able to receive switch
                                     commands correctly from the train controller and translate
                                     these commands into control instructions for the switch
                                     devices.
602-F     Switch Guards              Each switch is guarded by signals.                                 In Class [8 Feb 2000]
603-F     Switch Definitions         The switch has two states, Normal and Reversed. Normal             In Class [8 Feb 2000]
                                     implies the switch is oriented along the corresponding main
                                     line, whereas Reversed means the switch is oriented to direct
                                     traffic to another line.
604-F     Switch Display             In the traffic controller user interface the state of the switch   In Class [8 Feb 2000]
                                     must be visible (R or N to denote state or another
                                     representation).

900-F     Miscellaneous
901-F     Remote Train               As Stated: This system remotely controls trains. This              Description of TTCS
                                                                                                        [26 Jan 2000]
          Control                    requirement is considered outside the scope of the initial         In Class [01 Feb 2000]
                                     project.




        10 November, 2011                                                                                              9
95.590 Train Traffic Control System                                                                                                           Version 0.4
Requirement Summary Report




Scenario Analysis
This section will present a description of the overall context of system use as presented
in the Unified Modeling Language (UML) Use Case Diagram in Figure 2 and
subsequently provide Scenario Textual Descriptions describing individual system
scenarios related to the Train Traffic Control System (TTCS).




                                                                                                  approaching
                                                               Train Arriv e s in             subdivision boundary
                                                                 Subdiv ision

                                                   alert impending                                                   Incoming Train
                                                    incoming train

                                                                                                             update
                                                               Eme rge ncy Stop                       block / signal state



                                                stop all traffic


                                                             Change Signal                           update
                                                                                                  signal state
                                                                                                                               Train in
                                                                                                                             subdivision


                                    change block                         <<uses>>
                                       signal


                                                             Validate Train
                       raise exceptions                     Controlle r Input               OUTSIDE CURRENT SCOPE

                                change orientation                                    <<uses>>
                                    of switch
                                                                   <<uses>>
         Authorized                                                                                               control
                                                                                                                  sw itch
       Train Controller                                                             Change Switch
                                           initialize or restart                     Orie ntation


                    change orientation                        Initialize Syste m                                 control
                        of switch                                                                                sw itch         Sw itch on
                                                                                                                                   Track

                                                                   Train De parting
                                                                     Subdiv ision

                                                               <<uses>>             OUTSIDE CURRENT SCOPE



                                                         Monitor Train
                           update Train                   Movement                              report
          Authroized       / Block State                                               Train state and postion
        Train Controller

                                                                                                                                  Train in
                                                                                                                                subdivision



                                           Figure 2 - Complete Use Case Diagram



10 November, 2011                                                                                                                                     10
95.590 Train Traffic Control System                                                  Version 0.4
Requirement Summary Report


Context
Figure 2 provides a complete perspective of the context within which the Train Traffic
Control System is to be used. Based on the complexity of the system and the time
constraints placed on this initial project, the scenarios that will not be addressed in this
initial project are shaded. In principle, as stated previously in the system scope, the
initial project is limited to the interactions between the assigned or authorized Train
controller positioned in the train traffic control center and the Train Traffic Control
System. In general, there are three phases of operational activities that together form
the context in which the TTCS will be used. In principle the three phases correspond to
the life of a train’s passage through the subdivision. However, each phase is written
from the perspective of the Train controller’s interaction with the TTCS.

   Phase 1: Train Arrival. An incoming Train approaching the inbound subdivision
    boundary will request clearance to enter the subdivision via a communication
    medium. Designing the TTCS to handle train communication is currently considered
    outside the system scope.

    After receiving notice that a train is seeking clearance, the train controller will accept
    or refuse the clearance request. Upon acceptance of the clearance request the train
    will be created in the subdivision. If the signals are not appropriate for the train to
    enter the first block, then the train is placed in a queue outside the subdivision
    boundary. The train is only allowed to exist in one subdivision at a time and must be
    removed from the previous subdivision by the system (see Phase 3).

   Phase 2: Train Movement Through Subdivision. Once a train has entered the
    subdivision in question a number of possible scenarios may affect its movement
    through the subdivision. The impetus for each of these scenarios is based on Train
    controller input. The train controller influences movement through the subdivision by
    providing two types of input:

       changing signals for access to particular blocks of track;

       changing the orientation of switches;

    In accordance with safety requirements the train controller’s input must be validated
    by the system to ensure that dangerous traffic conditions do not result from the
    user’s input. The signals are displayed such that a particular entry signal is direction
    of travel dependent. That is a signal guards the entrance to a block from a
    eastbound or westbound direction, but not both. In addition to influence on train
    movement, the Train controller also has an override capability to stop a train from
    entering a block. This is considered an emergency capability to ensure complete
    safety in the physical environment.

    For the purposes of this initial project, the system scope limits this phase to consider
    the interaction between the train controller and the TTCS. In time the capabilities will
    be extended to facilitate updating information in the train itself.


10 November, 2011                                                                            11
95.590 Train Traffic Control System                                                Version 0.4
Requirement Summary Report




   Phase 3: Train Departure. As a train has proceeded through the clearance process
    implied by phase 1 in the next subdivision, its progress is also being monitored
    within the current train controller’s area of influence. Through a confirmation
    handshake to be determined, it is eventually considered to be departing the current
    subdivision. At this juncture a hand over of control between implicated subdivision
    Train Controllers is coordinated. That is, the departing train must be created in the
    next subdivision and subsequently removed from the current subdivision. As noted
    by the shaded region at the bottom of figure 1, the associated family of scenarios is
    currently considered outside the scope of this initial project.

    For the purposes of this project, the train controller will have explicit control over
    whether a train is removed from the subdivision. The TTCS will ensure that the
    necessary conditions are present to permit a trains removal. That is, for a train to be
    removed it must be in the block next to a system boundary with an intended direction
    of travel that will take the train outside of the subdivision.

Scenario Text Descriptions
The Scenario Text Descriptions considered through this initial Train Traffic Control
System project include:

   Initialize;
   Train Arrives in Subdivision;
   Emergency Stop;
   Change Signal;
   Change Switch Orientation;
   Validate Train Controller Input;
   Train Departs Subdivision.




10 November, 2011                                                                          12
       95.590 Train Traffic Control System                                                                Version 0.4
       Requirement Summary Report


                            SUBDIVISION

                       Block 1                         Block 2                             Block 3

                                      7                                         8
                           Block 4                   BLOCK 5                               Block 6




                                                       PHYSICAL
                                                     ENVIRONMENT




                                                                                      switches

                            Figure 3 - Dividing Physical Track into Subdivisions / Blocks
       In certain scenario text descriptions, special conditions will be depicted in figures. In
       particular, a figure will depict how the special conditions implied, relate to the behavior
       of partitioned of track sections. of subdivisions and blocks for the purposes of track
       management. As way of introduction, Figure 3 presents the hierarchy of partitioned
       track sections: subdivisions; and blocks for the purposes of physical track management.
       It should be noted that a block can have zero or many switches within it. However, each
       block has an entry and exit signal for each direction of travel.

STD Identifier: INITIALIZE SYSTEM                                                                         Requirement
                                                                                                           Reference
Description: A capability, owned by the train controller, by which action is initiated to initialize or
reset all signals and switches so that the subdivision is prepared to receive train traffic.
External Actors:
Train Controller
Train Switch
Precondition: There must be no trains in the current subdivision or its member blocks.
Triggering Event: Train Controller inputs initialization request.
Sequence of Responsibilities:
1. TTCS must validate the train controller input.
2. TTCS broadcast to all blocks to change signals to red.
3. TTCS broadcast to all blocks to change switches to normal position.
4. TTCS output message to Train controller that the TTCS is initialized.

Postcondition: All signals are red and all switches are normal.
Resulting Event: Enter a set of possible resulting events here.
Alternatives:

Nonfunctional Requirements: Enter a set of nonfunctional requirements that apply to the
scenario (optional)
Comments: Enter a comment section that may be used by designers as a free format text window
to specify different issues related to the scenario.



       10 November, 2011                                                                                          13
       95.590 Train Traffic Control System                                                                   Version 0.4
       Requirement Summary Report




STD Identifier: TRAIN ARRIVES IN SUBDIVISION                                                                 Requirement
                                                                                                              Reference
Description: Upon receiving clearance request indicating that a train is arriving, the train controller
must explicitly accept the clearance request before the train is created in the subdivision.
External Actors:
Train Controller
Precondition: Enter the precondition that must be satisfied in order to enable the execution of the
scenario.
Triggering Event: Train Controller receives clearance request from incoming train.
Sequence of Responsibilities:
1.
2.

Postcondition: Enter the postcondition that must evaluate to true after the execution of the
scenario.
Resulting Event: Enter a set of possible resulting events here.
Alternatives:
This scenario may also be used to initialize the system (that is all signals are originally set to red on
start-up)
Nonfunctional Requirements: Enter a set of nonfunctional requirements that apply to the
scenario (optional)
Comments: Enter a comment section that may be used by designers as a free format text window
to specify different issues related to the scenario.



STD Identifier: EMERGENCY STOP                                                                               Requirement
                                                                                                              Reference
Description: An override capability, owned by the train controller, by which the train controller
initiates action to stop all traffic in all blocks. Normally used by the train controller during emergency
situations.
External Actors: Enter the set of external actors that participate in the scenario.
Precondition: Enter the precondition that must be satisfied in order to enable the execution of the
scenario.
Triggering Event: Train Controller hits emergency stop button.
Sequence of Responsibilities:
1. Notify all block signals to change signals to red.
2. Blocks to acknowledge when all signals have been set to red.
3. Output message to Train controller that all signals have been set to red.

Postcondition: Enter the postcondition that must evaluate to true after the execution of the
scenario.
Resulting Event: Enter a set of possible resulting events here.
Alternatives:
This scenario may also be used to initialize the system (that is all signals are originally set to red on
start-up)
Nonfunctional Requirements: Enter a set of nonfunctional requirements that apply to the
scenario (optional)
Comments: Enter a comment section that may be used by designers as a free format text window
to specify different issues related to the scenario.




       10 November, 2011                                                                                             14
       95.590 Train Traffic Control System                                                                  Version 0.4
       Requirement Summary Report



            Triggering Event: Train
                                                          A. Validate that conditions are
            Controller inputs change
                                                          acceptable for change.
            eastbound signal to GREEN

                    Green

                    Yellow

                    Red
                    OK



                                             D. Change eastbound entry
                                             signal to GREEN.
                                        G
             East Bound
            Train arriving              R

                                              Block 1
                                                                  R                 Y                 Y

                                             C. Change westbound entry             B. Change westbound entries for
                                             signal to RED.                        safe # of blocks (2) to YELLOW.


                                     Figure 4 – Example of Change Entry Signal


                                                                                                           Requirement
STD Identifier: CHANGE SIGNAL TO ENTER A BLOCK                                                              Reference
Description: Based on the train controller’s initiative an entry signal can be changed. In order for a
inbound train to enter a particular block the signal must be green or yellow as given by the train
controller.
External Actors:
Train controller
Precondition: TTCS is initialized and ready for train controller input.
Triggering Event: The train controller inputs intent to change signal to yellow or green.
Sequence of Responsibilities:
1. TTCS validates the input change request.
2. Input change request validated, TTCS sends a message to target Block to change signal to be
    consistent with the input change request.
3. Block sends a message to the neighboring blocks in the opposite direction of the input change
    request. The number of blocks notified is must be in accordance with the variable number of
    blocks required for safe breaking. For the purposes of this project this number is two. The
    message is intended to change the entry signals to yellow.
4. Block sends a message to the entry signal in the opposite direction to change to Red. This will
    front protect the block.
5. Block sends a message to the entry signal corresponding to the input change request to
    change color consistent with change request.
6. Block returns to TTCS that the input change request has taken affect.
7. TTCS updates all the displayed information related to the signals, which have been changed in
    the train controller user interface.
8. [optional]TTCS informs the train controller that the request has been successfully processed.
Postcondition: TTCS in the state of being able to accept more commands from the controller
Resulting Event: TTCS inform the controller that the request has been successfully process
Alternatives:
1. If an incorrect or undetermined command has been detected then the command is refused and



       10 November, 2011                                                                                             15
       95.590 Train Traffic Control System                                                               Version 0.4
       Requirement Summary Report


                                                                                                        Requirement
STD Identifier: CHANGE SIGNAL TO ENTER A BLOCK                                                           Reference
   TTCS will inform the controller with a clear message. (see Validate Train Controller Input
   scenario)
2. If the input command violate the safety rule then the command is refused. TTCS will inform the
   controller with a clear message. (see Validate Train Controller Input scenario)
3. [To Be Confirmed] If TTCS fail to process the input command in 30 second then TTCS must
   inform the controller the situation.
4. If the signal device fail to respond to the request from TTCS. TTCS will inform the controller
   with a clear message and the request processing is considered as failure.
Nonfunctional Requirements:
 [To Be Confirmed]The request must be completed in less than 1 minute. Otherwise TTCS is
   considered as failing to process the request. If this is the case then TTCS must inform the
   controller which stage, the system has fail to execute the request (e.g. signal device has fail to
   comply to the request…)
Comments:
 008-A assumes physical signals are not dealt with in this project. However, in future there
   would need to be communication with a signal in order to affect the requested change.

   The input change request from the train controller may be cancelled at any time before the
    change color command is executed by the system. If the train controller cancels a command
    after the committed to changing signals then TTCS will issue a message to inform that the
    cancellation failed. In this case, the train controller may want to issue another changing signal
    command to reverse the effect from the previous command.




       10 November, 2011                                                                                         16
      95.590 Train Traffic Control System                                                               Version 0.4
      Requirement Summary Report




                                                                                                       Requirement
STD Identifier: CHANGE SWITCH ORIENTATION                                                               Reference
Description: Based on the train controller’s initiative the orientation of a switch is changed. The
changing of switch orientation is required in order control the route taken by a train through the
subdivision.
External Actors:
Train controller
Physical switch device.
Precondition: TTCS in the state of being able to accept more commands from the controller
Triggering Event: The controller issues command to change switch
Sequence of Responsibilities:
1. TTCS validates the input change request.
2. TTCS sends command to first and second switch device in the direction of the coming train to
    swich to the request track so that the train could enter the request track.
3. TTCS sends command to the third switch device to switch in the direction which prevents the
    train from coming back into the prohibited track (i.e. the main track)
4. TTCS sends command to the fourth switch device to switch in the direction which prevents a
    train coming from the other direction enter the sub-track.
5. TTCS sends command to exit signal device of the current block to change to red color to
    indicate the coming train must enter the sub train and wait there.
6. TTCS sends command to the entering signal device of the neighboring block (in the direction of
    the coming train) to change to red color to prevent other train from entering the block in the
    opposite direction.
7. The corresponding devices respond to the command issued by TTCS.
8. TTCS update all the information related to the switches which have been changed
9. TTCS informs the controller that the request has been successfully process.
10. TTCS provide the user interface the information to update the current stage.

Postcondition: TTCS is in the state of being able to accept more commands from the controller
Resulting Event: TTCS inform the controller that the request has been successfully process
Alternatives:
1. If an incorrect or undetermined command has been detected then the command is refused and
     TTCS will inform the controller with a clear message.
2. If the input command violate the safety rule then the command is refused. TTCS will inform the
     controller with a clear message.
3. If TTCS fail to process the input command in 30 second then TTCS must inform the controller
     the situation.
4. If the switch and signal device fail to response to the request from TTCS. TTCS will inform the
controller with a clear message and the request processing is considered as failure.
Nonfunctional Requirements: 1. The request must be completed in less than 1 minute.
Otherwise TTCS is considered as failing to process the request. If this is the case then TTCS must
inform the controller which stage, the system has fail to execute the request (e.g. switch or signal
device has fail to comply to the request…)
Comments: The command issues from the controller could be cancelled at any time before the
TTCS sent changing command to the switch or signal device. If the controller cancel a command
after the TTCS already send the command to the signal device then TTCS will issue a message to
inform that the cancellation fail. In this case, the controller may want to issue another changing
signal command to reverse the effect from the previous command.

      NOTE:
      1. we could divide this scenario into two parts:
         - Switch a train into a sub track (stop there waiting or using subtrack as its main track)
         - Switch a train from asub track into a main track.



      10 November, 2011                                                                                         17
95.590 Train Traffic Control System                                                            Version 0.4
Requirement Summary Report


2. The scenario describe above is for switching a train into a sub track then stop there. We can combine
these two scenario into one but we may need more If Else description for resposibilities.




10 November, 2011                                                                                      18
       95.590 Train Traffic Control System                                                               Version 0.4
       Requirement Summary Report




STD Identifier: VALIDATE TRAIN CONTROLLER INPUT                                                           Requirement
                                                                                                           Reference
Description: In order to ensure overall safety of train movement through the subdivision, the inputs    F14
of train controllers must be validated to ensure dangerous conditions are not cause. Although,
certain basic validation may be undertaken in individual scenarios, this particular validation is
critical to ensure the proximity of trains in neighboring blocks, before accepting a requested action
such as a signal request or change switch orientation request.
External Actors: Enter the set of external actors that participate in the scenario.
Precondition: Enter the precondition that must be satisfied in order to enable the execution of the
scenario.
Triggering Event: Enter the triggering event description here.
Sequence of Responsibilities:
1. Enter responsibility one here.
2. Enter responsibility two here
3. And so on

Postcondition: Enter the postcondition that must evaluate to true after the execution of the
scenario.
Resulting Event: Enter a set of possible resulting events here.
Alternatives: (optional) enter a set of alternative scenarios.
Nonfunctional Requirements: Enter a set of nonfunctional requirements that apply to the
scenario (optional)
Comments: Enter a comment section that may be used by designers as a free format text window
to specify different issues related to the scenario.

STD Identifier: TRAIN DEPARTS SUBDIVISION                                                                Requirement
                                                                                                          Reference
Description: A train is only allowed to exist on one sub-division at a time. When a train is in the
process of leaving the system it must be suitably removed from the TTCS.
External Actors: Enter the set of external actors that participate in the scenario.
Precondition: Enter the precondition that must be satisfied in order to enable the execution of the
scenario.
Triggering Event: Enter the triggering event description here.
Sequence of Responsibilities:
4. Enter responsibility one here.
5. Enter responsibility two here
6. And so on

Postcondition: Enter the postcondition that must evaluate to true after the execution of the
scenario.
Resulting Event: Enter a set of possible resulting events here.
Alternatives: (optional) enter a set of alternative scenarios.
Nonfunctional Requirements: Enter a set of nonfunctional requirements that apply to the
scenario (optional)
Comments: Enter a comment section that may be used by designers as a free format text window
to specify different issues related to the scenario.




       10 November, 2011                                                                                         19
95.590 Train Traffic Control System                                                       Version 0.4
Requirement Summary Report




References

[1] F. Bordeleau, A Systematic and Traceable Progression from Scenario Models to Communication
    Hierarchical State Machines (Ph.D. Thesis).




10 November, 2011                                                                                 20

				
DOCUMENT INFO
Shared By:
Stats:
views:562
posted:12/7/2009
language:English
pages:22
Description: train traffic control system