Scribd
Upload
40 views24 pages

Control Ans Command Traffic Management

This document discusses traffic management systems for train networks. It covers monitoring train traffic, defining the problem boundaries, requirements for a traffic management system, key abstractions like trains and tracks, and proposed mechanisms for message passing, train scheduling, displaying information, and sensor data acquisition. Diagrams show message and train plan classes, the display mechanism, and a top-level module diagram. Maintaining and expanding functionality is also addressed.

Uploaded by

mohd mursleen
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
40 views24 pages

Control Ans Command Traffic Management

This document discusses traffic management systems for train networks. It covers monitoring train traffic, defining the problem boundaries, requirements for a traffic management system, key abstractions like trains and tracks, and proposed mechanisms for message passing, train scheduling, displaying information, and sensor data acquisition. Diagrams show message and train plan classes, the display mechanism, and a top-level module diagram. Maintaining and expanding functionality is also addressed.

Uploaded by

mohd mursleen
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 24

Command and

Control:
Traffic Management

SUBMITTED TO:
DR. S.D. SAMANTARAY
WORK DISTRIBUTION FOR
MAKING THIS
PRESENTATION
Resource allocation- Sheetal Bisht (44069)
Designing-Noopur Joshi(44027)
Critical Validation-Rashmi Rani (44156)
Editing and Review-Pranita Singh and Nisha Joshi
TRAFFIC MONITORING
 TRAFFIC MONITORING IS THE TECHNIQUE OF
SUPERVISING THE FLOW OF CONTROL OF TRAFFIC
IN THE NETWORK.

OR

 IT IS AN OBJECT ORIENTED APPROCH TAKING IN


TO ACCOUNT THE USE OF UML FOR CONTORLLING
CONGESTION IN THE NETWORK.
Defining the Boundaries of
the Problem
As major metropolitan centers grow more crowded, light rail
transport is increasingly viewed as an attractive option to
easing congestion and addressing the problems of pollution
from internal combustion engines
Railroads are a business and consequently must be
profitable.
Railroad companies must delicately balance the demands of
frugality and safety and the pressures to increase traffic
against efficient and predictable train scheduling.
These conflicting needs suggest an automated solution to
train traffic management, including computerized train routing
and monitoring of all elements of the train system.
Such automated and semi automated train systems
exist today
The motivation for each of these systems is largely
economic and social.
 lower operating costs and more efficient utilization of
resources are the goals, with improved safety as an
integral by-product.
The architecture must be allowed to evolve over time.
The implementation must rely upon existing
standards to the largest extent practical.
Traffic Management System
RequirementsTraffic Management
System Requirements
The traffic management system has two primary functions:

• train routing
• train-systems monitoring.
Related functions include traffic planning, trainlocation
tracking, traffic monitoring, collision avoidance, failure
prediction, and maintenance logging.
Traffic Management System
Traffic Management System
The network control system is ultimately connected to one
or more dispatch centers, which comprise the rail-operations
control system and other users.
At the rail-operations control system, dispatchers can
establish train routes and track the progress of individual
trains.
Individual dispatchers control different territories; each
dispatcher's control console may be set up to control one or
more territories.
Train routes include instructions for automatically
switching trains from track to track, setting speed restrictions,
setting out or picking up cars,and allowing or denying train
clearance to a specific track section.
Dispatchers may note the location of track work along train
routes for display to train engineers.
Trains may be stopped from the rail-operations control
system when hazardous conditions are detected (such as a
runaway train, track failure, or a potential
collision condition).
Dispatchers can also call up any information available to
individual train engineers, as well as send movement
authority, wayside device settings, and plan revisions.
Track layouts and wayside equipment may change over
time.
 The numbers of trains and their
routes may change daily.
The system must be designed to permit incorporation of new
sensor, network, and processor technology.
Scenario for Processing
Daily Train Orders
Traffic Management System
Process Diagram
Key Abstractions and
Mechanisms
A study of the requirements for the traffic management
system suggests that we really have four different sub
problems to solve:
• Networking
• Database
• Human/machine interface
• Real-time analog device control
If we do a brief domain analysis across these four problem areas,
we find that there are three common high-level key abstractions:
• Trains Including locomotives and cars
• Tracks Encompassing profile, grade, and wayside
devices
• Plans Including schedules, orders, clearances,
Every train has a current location on the tracks, and each
train has exactly one active plan.
Similarly, the number of trains at each point on the tracks
may be zero or one.
for each plan there is exactly one train, involving many
points on the tracks.
Continuing, we may devise a key- mechanism for each of
these four nearly independent
Sub problems:
• Message passing
• Train-schedule planning
• Displaying
• Sensor data acquisition
These four mechanisms form the soul of our system.
They represent approaches to what we
have identified as the areas of highest development risk
Message Class Diagram
typical messages in the traffic management system
include signals to activate wayside devices, indications
of trains passing specific locations, and orders from
dispatchers to train engineers.
 these kinds of messages are passed at two different
levels within the traffic management system:
• Between computers and devices
• Among computers
Our interest is in the second level of message
passing.
Because our problem involves a geographically
distributed communications network, we must consider
issues such as noise,equipment failure, and security.
Message Class Diagram
Message Passing Mechanism
Train-Schedule Planning
the concept of a train plan is central to the operation
of the traffic management system.
 Each train has exactly one active plan, and each plan
is assigned to exactly one train and may involve many
different orders and locations on the track.
For example, a specific train plan might consist of the
following actions:
Train Plan Class Diagram
Train-Schedule Planning
Displaying

The principle advantage of this approach is that it limits the


impact of any lower-level changes resulting from
hardware/software trade-offs.
For example, if we find that we need to replace our display
hardware with more or less powerful devices, then we need
only reimplement the routines in the class Train Display
Utilities. Without this collection of routines,low-level changes
would require us to modify the implementation of every
displayable object.
Traffic Management System
Top-Level Module Diagram
Maintenance
Adding New Functionality
Our solution would be to add a new subsystem
between the subsystems Train Plan Database and
Dispatcher Applications, because the knowledge base
embodied by this expert system parallels the contents
of the Train Plan Database.
 furthermore, the subsystem Dispatcher Applications
is the sole client of this expert system. We would need
to invent some new mechanisms to establish the
manner in which advice is presented to the ultimate
user.
Refrences
[1] Murphy, E. December 1988. All Aboard for Solid State.
JEE-E Spectrum vol. 2503),
p. 42.
[2] Rockwell Advanced Railroad Electronic Systems.
1989. Cedar Rapids, IA: Rockwell
International.
[3] Tanenbaum, A. 1981. Computer Networks. Englewood
Cliffs, NJ: Prentice-Hall.
Thank You

You might also like