DESIGN AND EVALUATION OF A
COMMUNICATIONS DEVICE TO ENHANCE
RAILROAD WORKER SAFETY
by
Nicolas Oriol Hoyos
B.S., Electronics Engineering
ICAI - Madrid, Spain, 1997
Submitted to the Department of Mechanical Engineering
in Partial Fulfillment of the Requirements for the Degree of
Master of Science
at the
Massachusetts Institute of Technology
June 2000
C 2000 Massachusetts Institute of Technology
All Rights Reserved
..........
......................
Signature of Author: ...............
Department of Mechanical Engineering
February 29, 2000
...................
C ertified by : ..........................................
Thomas B. Sheridan
Professor of Engineering and Applied Psychology
Thesis Supervisor
A ccepted by : ............................
. ................................
MASSACHUSETrS INSTITUTE
-CP 20 2000
LIBRARIES
........
Ain A. Sonin
Chairman, Department Committee on Graduate Students
2
DESIGN AND EVALUATION OF A
COMMUNICATIONS DEVICE TO ENHANCE
RAILROAD WORKER SAFETY
by
Nicolas Oriol Hoyos
Submitted to the Department of Mechanical Engineering
on February 29, 2000 in Partial Fulfillment of the
Requirements for the Degree of
Master of Science
Abstract
Communications in current railroad operations are heavily based on voice links. Radio
congestion is often a problem when roadway workers try to establish communication with
dispatchers at the Traffic Control Center. This problem is expected to grow with the introduction
of new rail services. At the same time, roadway worker fatalities still occur every year.
In this work we developed and tested a prototype of a communications system to be used
by roadway workers and dispatchers that was based in a wireless data link device. Our goal was
to increase safety of roadway workers and at the same time to reduce radio congestion improving
overall efficiency of railroad operations. To fulfil these objectives the data link device was used
both to receive real time information about train location and to transmit work permissions
electronically.
Although the prototype was shown to have room for improvement, the result of our
experiments showed that the goals of reducing radio congestion and improving roadway worker
safety could be achieved simultaneously and with a device that is easy to use for roadway
workers and has good acceptance among them.
Thesis Supervisor: Thomas B. Sheridan
Title: Professor of Engineering and Applied Psychology
3
Acknowledgments
The author would like to acknowledge several people who helped in the development of this
work. First, Prof. Thomas Sheridan from MIT and Dr. Jordan Multer from Volpe National
Transportation Systems Center provided both support and guidance. Nicolas Malsch and Santanu
Basu, from MIT, developed the train dispatcher simulator that was the launch pad for this
project. John K Pollard, Mike Zuschlag and Andrew Kendra from Volpe National Transportation
Systems Center and Emilie Roth provided help in their own field of expertise. David
Lecumberri, from MIT, helped in the early steps of the PID by envisioning a feasible system
architecture. Timothee Masquelier, from MIT, reviewed the appendix drafts. Steve Jones, from
Amtrak, provided the invaluable help of arranging visits to the Traffic Control Center at Boston
South Station. Brian Radovich, from Amtrak, arranged the visits to work sites and volunteered to
find test users for the experiment. All the test users, that were willing to test the device, provided
excellent ideas to improve it and showed great enthusiasm.
In addition, the sponsor, the Federal Railroad Administration, Office of Research and
Development under contract DTRS57-98-D-00043 with Volpe National Transportation Systems
Center, US DOT, provided financial support for this work.
4
Table of contents
G LO SSAR Y ................................................................................................................................................................
IN TRO D U CTION ...........................................................................................................................................
1
1.1
OVERVIEW OF COMMUNICATION CHANNELS IN ACTUAL RAILROAD OPERATIONS..........................................
O VERALL OBJECTIVE.....................................................................................................................................
1.2
2
M O TIVA TIO N................................................................................................................................................
2.1
2.2
PREVIOUS W ORK ...........................................................................................................................................
ROADW AY W ORKER PROTECTION..................................................................................................................
M ETHO D O LO GY ..........................................................................................................................................
3
3.1
COGNITIVE TASK ANALYSIS. PILOT STUDY....................................................................................................
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.2
PROTOTYPE DESIGN.......................................................................................................................................
3.2.1
3.2.2
3.2.3
3.2.4
3.3
Information sharedby roadway workers and dispatchers...............................................................
Actions and cognitiveprocessesperformed by dispatchers and roadway workers. .......................
Dispatcherand roadway worker comments aboutproposed tools to enhance their safety. ............
Hum an-m achine interface...................................................................................................................
Conclusion of the pilot study...............................................................................................................
Alternatives .........................................................................................................................................
Palm VII: Advantages and disadvantages.......................................................................................
Palm VII: Security, authenticationand training..............................................................................
PID system architecture......................................................................................................................
EXPERIM ENTS ...............................................................................................................................................
3.3.1
3.3.2
3.3.3
Overview .............................................................................................................................................
Early tests ...........................................................................................................................................
Laboratorytests. .................................................................................................................................
R ESU LTS A N D D ISC U SSIO N ......................................................................................................................
4
4.1
4.2
4.3
9
11
11
12
14
14
15
20
20
20
22
26
27
28
30
30
30
32
33
35
35
35
36
42
M EASURES TAKEN AND M ETHOD OF ANALYSIS. ..........................................................................................
DIFFERENCE BETWEEN RADIO AND DATA LINK COMMUNICATIONS. ...........................................................
42
44
4.2.1
Data link device results in safer operations.....................................................................................
Data link device results in better knowledge ofpotential risks but in reducednumber ofjobs
4.2.2
completed. .........................................................................................................................................................
4.2.3
Communicationseems to be slower but more accurate using the data link device. The workload
remains the same...............................................................................................................................................
44
POTENTIAL IMPLEMENTATION OF A DATA LINK DEVICE IN RAILROAD OPERATIONS. ..................................
51
48
49
51
Favorableacceptance of the data link device, with some conditions. ..............................................
4.3.1
Features that a data link device must have before it is introducedin real railroadoperations......... 51
4.3.2
4.3.3
Featuresthat would improve the acceptance of the data link device but are not requiredfor its basic
52
operation. ..........................................................................................................................................................
54
Other potential uses of the data link device. ....................................................................................
4.3.4
5
C O N CLU SION S..............................................................................................................................................
5
55
APPEND IX A . PID SY STEM AR CH ITECTURE .............................................................................................. 57
A . 1.
COMPONENTS ........................................................................................................................................... 57
A. 1. 1. PID device...........................................................................................................................................
A. 1. 2. Web server..........................................................................................................................................
A-1-3.
Query servers......................................................................................................................................
A . 1 .4 . Da tab ase.............................................................................................................................................
A. 1. 5. Dispatcherinterface............................................................................................................................
A. 1. 6. Database manager interface...............................................................................................................
A .2.
TYPE OF REQUESTS ...................................................................................................................................
A .3.
M ASTER FILES ..........................................................................................................................................
A .4.
FUNCTIONALITY .......................................................................................................................................
A. 4. 1.
Database requests...............................................................................................................................
A. 4.2. Dispatcher requests ............................................................................................................................
A .5.
CONFIGURATION FILE ...............................................................................................................................
57
62
62
68
74
75
76
82
go
90
92
93
APPEND IX B. Q U ESTIONNA IRES .................................................................................................................... 94
APPEND IX C. DETAILED EXPERIM EN T RESULTS .................................................................................. 105
APPENDIX D . FO R M D ...................................................................................................................................... 130
R EFER ENCES ....................................................................................................................................................... 132
List of Figures
FIGURE I -I
FIGURE 1-2
FIGURE 2-1
FIGURE 2-2
FIGURE 2-3
FIGURE 2-4
FIGURE 3-1
BASIC INFORMATION FLOW IN RAILROAD OPERATIONS...........................................................................
PROPOSED INFORMATION FLOW BETWEEN ROADWAY WORKERS AND DISPATCHERS ..............................
ROADW AY W ORKER FATALITIES 1986-JUNE 1999................................................................................
AVERAGE AGE AND YEARS OF SERVICE. .................................................................................................
V EHICLE SPEED ........................................................................................................................................
TYPE OF ROADW AY WORKER...................................................................................................................
PROPOSED FUNCTIONALITIES OF THE PID ..............................................................................................
FIGURE 3-2
FIGURE 3-3
FIGURE 3-4
FIGURE 3-5
PALM V II .................................................................................................................................................
PID SYSTEM ARCHITECTURE ....................................................................................................................
PID - M AIN M ENU (EARLY VERSION) ......................................................................................................
M AIN M ENU (AFTER EARLY TESTS)..........................................................................................................
FIGURE 3-6 U SABILITY TEST, SETUP............................................................................................................................
FIGURE 3-7 SYSTEM EVALUATION TEST, SETUP...........................................................................................................
FIGURE 4-1 INFORM ATION RETRIEVED ........................................................................................................................
FIGURE 4-2 INFORM ATION REMEMBERED....................................................................................................................
FIGURE 4-3 SAFETY ERRORS AND W RONG W ORK REQUESTS........................................................................................
FIGURE 4-4 W ORK REQUESTS SENT .............................................................................................................................
FIGURE 4-5 AVERAGE TIMES FOR SUCCESSFUL INTERACTIONS..................................................................................
FIGURE 4-6 COMM UNICATION ERRORS........................................................................................................................
FIGURE A -I DISPATCHER INTERFACE..........................................................................................................................
FIGURE A -2 D ATABASE MANAGER INTERFACE.........................................................................................................
FIGURE A -3 RENDERING OF MASTERTRAiNSTATUS.HTML .......................................................................................
FIGURE A-4 INDEX.HTML ............................................................................................................................................
FIGURE A -5 TSCHW ORKINGSITE.HTML ......................................................................................................................
FIGURE A -6 O VER THE AIR ICON .................................................................................................................................
FIGURE B-1 DEM OGRAPHIC QUESTIONNAIRE ..............................................................................................................
FIGURE B-2 U SABILITY TEST. QUESTIONNAIRE (1) ..................................................................................................
FIGURE B-3 U SABILITY TEST. QUESTIONNAIRE (2) .....................................................................................................
FIGURE B-4 U SABILITY TEST. QUESTIONNAIRE (3)..................................................................................................
FIGURE B-5 U SABILITY TEST. Q UESTIONNAIRE (4) ..................................................................................................
FIGURE B-6 U SABILITY TEST. QUESTIONNAIRE (5)...................................................................................................
FIGURE B-7 U SABILITY TEST. QUESTIONNAIRE (6) ...................................................................................................
FIGURE B-8 SYSTEM EVALUATION TEST. QUESTIONNAIRE (1) ..................................................................................
FIGURE B-9 SYSTEM EVALUATION TEST. QUESTIONNAIRE (2)..................................................................................
FIGURE B-10 SYSTEM EVALUATION TEST. QUESTIONNAIRE (3) ................................................................................
FIGURE B-Il SYSTEM EVALUATION TEST. QUESTIONNAIRE (4)................................................................................
FIGURE D - FORM D .................................................................................................................................................
7
12
14
16
17
17
18
29
31
34
35
36
39
41
45
47
47
48
49
50
75
76
82
90
90
91
95
96
97
98
99
100
101
102
103
104
104
130
List of Tables
TABLE 3-1 ROADWAY WORKERS THAT INTERACT WITH DISPATCHERS.....................................................................
TABLE A-I PID SCREEN SHOTS (1).............................................................................................................................
TABLE A-2 PID SCREEN SHOTS (2) .............................................................................................................................
TABLE A-3 PID SCREEN SHOTS (3) .............................................................................................................................
TABLE A-4 PID SCREEN SHOTS (4) .............................................................................................................................
TABLE A-5 EXAMPLE OF DISPATCHER'S DATA FILE. .................................................................................................
TABLE A-6 EXAMPLE OF ROADWAY WORKER'S DATA FILE .......................................................................................
TABLE A-7 EXAMPLE OF TRACK INFORMATION DATA FILE .......................................................................................
TABLE A -8 EXAMPLE OF TRAIN SCHEDULE DATA FILE ................................................................................................
TABLE A-9 EXAMPLE OF TEST USER'S TASKS DATA FILE...........................................................................................
TABLE A- 10 EXAMPLE OF INITIAL TRAIN DELAYS DATA FILE....................................................................................
TABLE A-II DATABASE QUERY SERVER PARAMETERS. ...........................................................................................
TABLE A-12 DISPATCHER QUERY SERVER PARAMETERS (1) ....................................................................................
TABLE A- 13 DISPATCHER REQUESTS PARAMETERS (2) ...........................................................................................
TABLE A-14 FILE QUERY SERVER PARAMETERS........................................................................................................
TABLE A-15 TERMINAL REFRESH QUERY SERVER PARAMETERS .................................................................................
TABLE A- 16 SIMULATION QUERY SERVER PARAMETERS...........................................................................................
TABLE A- 17 M ASTER CLIPPING FILES (1)....................................................................................................................
TABLE A- 18 MASTER CLIPPING FILES (2)....................................................................................................................
TABLE A- 19 M ASTER CLIPPING FILES (3) ....................................................................................................................
TABLE A-20 M ASTER CLIPPING FILES (4) ....................................................................................................................
TABLE A-21 M ASTER CLIPPING FILES (5)....................................................................................................................
TABLE
TABLE
TABLE
TABLE
A-22 MASTER HTM L FILES (1).......................................................................................................................
A-23 M ASTER HTM L FILES (2).......................................................................................................................
A-24 MASTER SIMULATION FILE ......................................................................................................................
A-25 FILES STORED IN THE PALM VII (PQA) ................................................................................................
8
23
58
59
60
61
69
69
71
72
73
74
77
78
79
80
81
81
83
84
85
85
86
87
88
88
89
Glossary
Block Signal: A fixed signal displayed to trains at the entrance to a block to govern use of
that block. 1
Block: A length of track with defined limits on which train movements are governed by
block signals, cab signals or Form D. 1
Blocking device: A lever, plug, ring or other method of control that restrict the operation of
a switch or a signal.
2
Cab signal: A signal that is located in the engine control compartment and which indicates
track occupancy or condition. The cab signal is used in conjunction with interlocking signals and
in lieu of block signals. I
Controlled track: Track upon which the railroad's operating rules require that all
movements of trains must be authorized by a train dispatcher or a control operator.
2
Dark territory: A section of track that is not signaled. In dark territory, the train dispatcher
does not get automatic indication of the location of the trains, nor does the train get automatic
signals allowing movement through the territory.
3
Data link: Technology that enables information that is now transmitted over radio links to
be transmitted over data lines.
3
Fixed signal: A signal at a fixed location that affects the movement of a train.
1
Flagman: When used in relation to roadway worker safety, means an employee designated
by the railroad to direct or restrict the movement of trains past a point on track to provide ontrack safety for roadway workers, while engaged solely in performing that function.
2
Foul time: Method of establishing working limits on controlled track in which a roadway
worker is notified by the train dispatcher or control operator that no trains will operate within a
specific segment of controlled track until the roadway worker reports clear of the track. 2
Fouling a track: Placement of an individual or an item in such a proximity to a track that
the individual or equipment could be struck by a moving train or on-track equipment, or in any
case is within four feet of the field side of the near running rail.
9
2
Interlocking: An interconnection of signals and signals appliances such that their
movements must succeed each other in a predetermined sequence, assuring that signals cannot be
displayed simultaneously on conflicting routes. 2
Movement Permit Form D: A form containing written authorization(s), restriction(s), or
instruction(s), issued by the dispatcher to specified individuals. I
On-track safety: State of freedom from the danger of being struck by a moving railroad
train or other railroad equipment, provided by operating and safety rules that govern track
occupancy by personnel, trains or on-track equipment.
2
Real time train OS: Dispatcher's term that refers to train schedule with time updates.
Roadway worker: Any employee of a railroad, or of a contractor to a railroad, whose duties
include and who is engaged in the inspection, construction, maintenance or repair or railroad
track, bridges, roadway, signal and communication systems, electric traction systems, roadway
facilities or roadway maintenance machinery on or near the track or with the potential of fouling
a track, and employees responsible for their protection. 1
Shunt: Activate block or interlocking signals when present on track. 3
Track car: Equipment, other than trains, operated on a track for inspection or maintenance.
Track cars might not shunt track circuits.
2
Train dispatcher: Railroad employee assigned to control and issue orders governing the
movement of trains on a specific segment of railroad track in accordance to the operating rules of
the railroad that apply to that segment of track. 2
1NORAC operating rules
2
3
Roadway Worker Protection Manual (RWP manual)
Roth, E.M. and Malsch, N.1999
10
1
Introduction
1.1
Overview of communication channels in actual railroad operations
Of all the employees working in railroad operations, three main groups play a key role:
railroad dispatchers, locomotive engineers and roadway workers:
*
Railroad dispatchers. Their most important responsibilities are to insure safe movement of
trains and personnel on the track, to insure that passenger trains meet schedule and, in case of
emergency, to coordinate rescue missions.
*
Locomotive engineers. They are responsible to follow the directions dictated by wayside
signals and dispatchers.
0
Roadway workers. Perform maintenance as well as construction of new sections of track,
platforms, signals, switches, electrification posts, draw bridges and any other track related
asset.
Apart from the railroad operators, it is worth mentioning the role that the equipment itself
plays. The switches and signals receive commands from the dispatcher's terminal and the track
geometry is modified accordingly. Except in the case of the so-called dark territory, the ground
equipment sends back to the dispatchers information about the actual state of switches and
signals as well as information about train location.
These three human groups, together with the track infrastructure, are engaged in a constant
exchange of information with the dispatcher being the core and supervisor of the overall system.
As we can see in Figure 1-1 the information flow is based in oral communication using either
radio or telephone calls between the human operators. Digital or automated communication is
used mainly between the track and the dispatcher's terminal (Ditmeyer, S.R. and Smith, M.E.,
1993).
Figure 1-1 does not show all possible communication channels in railroad operations.
Communication between roadway workers and engineers also takes place and is essential to safe
operations. Current railroad infrastructure is being built in such a way that wayside signals are
continuously exchanging information with the train. This is the case of the ongoing project of
high-speed railroad network in Europe (Wojanowski E, 1998 and Lestime H. 1998). But the vast
11
majority of the current railroad networks, especially in the US, operate under a communications
pattern similar to Figure 1-1.
I
Track
Infrastructure
-
-
Train location
Switch state
Signal state
F
11
HI
r _ _ _ _- _ _I Dispatcher's
terminal
-
Train speed restrictions
Movement authority
Other trains location
Locomotive
Engineer
-
Commands
I
Train location request
Train schedule request
Work permission request
Protection request
Emergency
Other: submit speed
restrictions, pass stop
signal request...
-
User
Interface
Roadway
Worker
Dispatcher
-
Hazard report
Emergency
Information request
Movement request
Permission to work
Protection
Train location
and schedule info
Data link
Human operator
Electronic device
Po Oral communication
Figure 1-1 Basic information flow in railroad operations
1.2 Overall objective
Currently voice radio channels are congested and are quickly approaching their capacity.
There is not enough available bandwidth to support current communication needs (Roth, E.M.
and Malsch, N. 1999). Furthermore, as it is shown in Figure 1-1 some of the dispatcher's
outgoing messages are dedicated to forwarding information from computer databases, such as
train schedule and current train delays, to other railroad employees. This may cause distraction
from their most important task: insure safety.
12
With these two ideas in mind (radio congestion and safety concerns) the overall goal of the
program in which this project was included was:
"To explore the informationflow in railroadoperations and look for potential uses of new
information technologies in order to enhance safety in railroadoperations.In particular,the use
of data link has been proposed as an alternative communication medium to supplement voice
radio"
Our interest was to understand the safety implications of data link. We were looking for data
link tools that enabled better communications in terms of safety and efficiency.
Earlier studies had looked at data link potential from the point of view of the dispatchers
(Malsch, N. 1999 and Basu, S. 1999). It was the purpose of this project to analyze this issue from
the roadway worker perspective. What could be done at the roadway worker side to enhance
safety through data link communications? Were the roadway workers ready to use new
information technologies? What were the minimum requirements that must be addressed before
the roadway workers used data link technologies? Was the effort worthy?
Our idea was not to find a replacement for radio. We were looking for some structured
interactions between dispatchers and roadway workers that might be shifted to other electronic
media. The idea was to reduce radio congestion while increasing safety in railroad operations.
We proposed the use of new information technologies in order to fulfil these requirements.
We provided the roadway workers with a device that let them establish direct communication
with the Traffic Control Center in order to retrieve vital information, previously not available,
without distracting the dispatcher with radio calls. The information flow between dispatchers and
roadway workers was modified to be closer to Figure 1-2.
13
Emergency
Other non structured
-
Train location
Train schedule update
Work permission
Protection
Territory information
communication:
equipment details, verbal
permission,
l
i
i
...
I
Dispatcher's
terminal
I
rN
Personal
I
I
Information
I
I
Device (PID)
User
Interface
User
Interf ace
Dispatcher
FL
.1
I
LI-
I
Roadway
Worker
Human operator
Data link
Electronic device
Oral communication
--
Figure 1-2 Proposed information flow between roadway workers and dispatchers
2 Motivation
2.1
Previous work
The present project was born as an extension of the above-mentioned FRA program. During
the experiments conducted by Nicolas Malsch (Malsch, N. 1999) and Santanu Basu (Basu, S.
1999), where the potential of data link technologies was tested from the point of view of
dispatchers, the test users made several suggestions. Some of these ideas directly addressed the
issue of communication of dispatchers with roadway workers. Among these suggestions we
highlight the following:
Dispatchers liked the idea of datalink technologies. They liked the fact that they could
receive requests from trains or work crews in an e-mail like fashion instead of radio calls that
had to be answered in a first-come first-served basis. With this architecture, they could assign
priorities to incoming messages and deal first with the most important ones.
14
* They did not see how the work crews in the field would send them digital messages. Not only
did they not have the appropriate tool but also some of them were not familiar with
computers.
" They found interesting the fact that with data link they did not have to repeat a message
many times due to low quality radio transmissions.
" They welcomed a system that helped to solve the congestion problem that affected radio
communications.
Also, during a preliminary cognitive task analysis used to understand how train dispatchers
manage and control trains (Roth, E.M. and Malsch, N., 1999) dispatchers suggested a list of
ideas for improving dispatch operations. Among these ideas was mentioned the concept of
transmitting messages and authorization forms over electronic media.
So with all these ideas in mind we conducted some interviews, described below, with
dispatchers. We paid special attention to their interaction with roadway workers. Interviews were
also held with roadway workers. The goal of the analysis was to gain a better understanding
about how new information technologies could be applied to the job of a roadway worker.
2.2
Roadway worker protection
Concern regarding hazards faced by roadway workers has existed for many years. In 1996,
after an initial petition form the Brotherhood of Maintenance of Way Employees (BMWE), the
FRA amended Part 214 (Railroad workplace safety) of Title 49 (Transportation), Code of
Federal Regulations by adding a new subpart. Subpart C: Roadway Worker Protection (see FRA
web page). This new subpart was the result of the work done by the Roadway Worker Safety
Advisory Committee. This committee was established on December 1994 and comprised 25
members of different organizations including unions, railroads, FRA, APTA and several
brotherhoods of locomotive engineers and maintenance of way employees.
Apart from the government effort to regulate roadway worker safety, it is worth analyzing
the relevance of roadway worker accidents in the past. A recent report from the US Department
of Transportation, prepared for an update of Subpart C, has compiled fatal accidents of roadway
workers during the past 13 years. The figures in this section have been obtained from the
15
mentioned report (FRA report, 1999). In the US, as of June 1999, 60 roadway workers had been
killed since 1986 while they were on duty. This figure includes roadway workers from all the
different railroads in the US.
Total = 60
9-
8
Advisory Committee
Formed
87
7
6
6
BMWE
.
7
6
Voluntary
Implementation Class 1
Railroads Mid 1996
Compliance
Mid 1997
5 -
4
4
4
''--..
ICU
U-
3
2
0
II . I
86
87
I
I
88
I
89
I
90
I
92
91
93 94 95
96 97
98 99
Graph does not include one Conductor Flagman fatality in 1997
As of June 9, 1999k
Figure 2-1 Roadway worker fatalities 1986-June 1999
We can see in Figure 2-1, the milestones of Roadway Worker Protection FRA rule together
with the distribution of roadway worker fatalities during this period.
It is worth mentioning two striking results of this report. The first of them is the average age
(42 years) and average years of service (18 years) of the roadway workers involved in these fatal
accidents. We can see in Figure 2-2 that less than a third of the fatalities occurred to less
experienced roadway workers, and only a bit more than 10% were among the youngest roadway
workers. These results suggest that inexperience or youth are not among the main possible
contributing factors and they point more towards complacency.
16
-
Age
-
20 - 30
Years Service
12%
0-10
29%
21+
40%
31 -40
122%
41-50
11 -20
W
44%
31%
Average Years Service 18
Average Age 42
Figure 2-2 Average age and years of service.
The second striking result is the speed of the trains or other on-track equipment that caused
the fatalities. Figure 2-3 shows that a third of the fatalities were due to relatively slow equipment
(10-20 mph) and that only 13 (22%) were due to speeds above 60 mph.
61+
13
11
41-60
CL
CO
21-40
16
10-20
20
j
Fatalities
Figure 2-3 Vehicle Speed
Finally, considering the different types of incidents, we can see in Figure 2-4 that almost
three fourths of the accidents could be included in three main types of incidents: roadway
workers struck by a train while working, struck by a train in the adjacent track or roadway
17
workers that walked into train path. The first group includes accidents in the same track were the
roadway worker was doing his/her duties. The second group includes accidents in the track
parallel to it. The third group includes accidents while the roadway worker was preparing to do
his/her job or while he/she was not doing a job on the track but in its vicinity and he/she walked
into the train path with the intention, for example, of crossing the main track.
MW Equipment
18%
Other
7%
Train While
Working
37%
Free Rolling
Cars
7%
Train Adjacent
Tr
Walked Into
Train18TrainTrack
ac
13%
Figure 2-4 Type of Roadway Worker
Figure 2-4 suggests that not knowing about real time train location is a possible contributing
factor to fatal accidents. One of the uses of data link technologies that we proposed in this project
dealt precisely with this issue. We presented data link as a way to send, among other data,
information about real time train location to roadway workers. The Traffic Control Center
already knew this information and we were looking into ways of sending it to roadway workers.
A recent report (SOFA working group, 1999) discussed railroad employee fatalities
involved in switching operations. One of the findings of the SOFA group (Switching Operations
Fatality Analysis) is that communications is an area that can be improved to reduce the number
of fatalities derived from switching operations. Although the main focus of this project was
roadway workers, we believe that some results can be extrapolated to switching operations.
Roadway worker fatalities are an issue in the railroads around the globe. As an example let
us mention that during the same 13-year period, more than 100 railroad workers were killed in
18
Japan. Very recently, in January 2000, two roadway workers were struck by a freight train and
killed in Spain while they were operating a crane under very low visibility conditions due to a
dense fog. In November 1999, in Boston, the last train of one of the T-lines, that happened to be
unusually delayed, killed a roadway worker who was not aware of this delay.
There are also accidents due to disorientation of the roadway worker. This is the case of a
roadway worker that had asked appropriate protection from the dispatcher to work on a track that
he was not really occupying. Without his knowledge, he was working unprotected on the wrong
track.
Some other accidents are due to abuse of current means of communication. This is the case
of a work crew who had heard over the radio that another crew was working under protection
some miles down the same track. Not following the rules, they did not call the dispatcher for
protection and kept an hear on the radio just in case the other crew finished their job and gave the
track back to the dispatcher. They were misusing the party line feature of radio communication.
The fact was that the second crew had finished their job and had given the track back to the
dispatcher using an acceptable regular phone call, not the radio. The first crew never heard that
the protection was removed and got hit by a train.
Some, not all, of these accidents may have been avoided if the crews had had real time
information about train location. The accident due to wrong orientation in the track could have
been avoided if the roadway worker had carried a GPS device that would have sent his or her
exact location to the dispatcher center. The accident due to the misuse of another crew's
protection may have been avoided if the crew had had real time information about what track
was out of service.
Dispatchers know near real-time information about train location. We proposed giving this
information to the work crews in real time. For this purpose we used data link technologies.
19
3 Methodology
The project was divided in three main parts:
" Cognitive task analysis.
" Prototype Design.
" Experiments.
3.1
Cognitive task analysis. Pilot study.
In previous work, a CTA (Roth, E.M. and Malsch, N., 1999) was conducted to understand
how train dispatchers manage and control trains. This report was very helpful during the
development of the present project but it lacked from the perspective of the roadway worker. All
the ideas and suggestions proposed in this CTA came from dispatchers without participation of
roadway workers. This is why we decided to conduct a smaller CTA with emphasis on the
interactions between dispatchers and roadway workers.
During three shifts the work of three different dispatchers was observed paying special
attention to their communication with roadway workers. Also, with the idea of looking at the
problem from both ends, observations of track maintenance work were also conducted. Both the
dispatchers and the roadway workers were questioned about potential tools aimed to improve
their communication system. Their comments on the benefits and drawbacks of these tools were
annotated and are presented bellow. They also helped in the conceptual design of the prototype
of the information device that was developed and tested in this project.
3.1.1
Information shared by roadway workers and dispatchers
We could identify two different types of messages between dispatchers and roadway
workers. The first type includes all those messages following a pattern given by the rules and
that everybody must follow. We will call them structured messages. The second type includes all
other messages and we will call them unstructured messages.
20
Structured messages
1.
Movement permit form D and additions to form D.
According to the operating rules (NORAC operating rules, 1999), "the dispatcher issues form
D's to restrict or authorize movements. Form D's are also issued to convey instructions not
covered in the Operating rules". Although Form D's are mainly designed to be sent to trains,
according to one of the interviewed dispatchers, 90% are issued to work crews and only 10%
to trains. A roadway worker may receive a form D line 4 "if the work involves on-track
equipment or will disturb the track or catenary structure so that it would be unsafe for normal
speed."
Once a dispatcher has issued a form D and it is effective, very limited information may be
added to it. This information includes cancellation facts, additional line 2 authorities
(permission to continue to operate a track car in a given direction under new limits) and
"track is clear" information in line 13 (train or track car ahead has cleared the limits of the
following track car's line 2 authority). A more detailed description of a form D is given in 1.
See NORAC operating rules for a full description of Form D.
2. Foul Time.
A qualified roadway worker whose duty will not disturb the track or catenary structure may
receive verbal authorization to foul the track (Foul Time) from the dispatcher. Issuing foul
time to roadway workers has become a major part of a dispatcher's job. Depending on the
territory under consideration, a dispatcher may easily have three to seven active foul times in
his or her territory at the same time. This is why Foul Time is actually written in a standard
form. See NORAC operating rules for a full description of Foul Time.
3. Rule 241 authority to pass a stop signal.
Rule 241 authority is used to let trains or track cars pass a stop signal. It is issued most often
to track cars since they need this authorization to enter each interlocking. Almost every time
a form D line 2 (permission to operate a track car) is issued, it is followed either by a form D
line 3 (track car proceed past stop signal) or a rule 241. Which authority to pass a stop signal
is issued to the track car depends on the dispatcher's preferences. See NORAC operating
rules for a full description of rule 241.
21
4. Speed restrictions.
Repair crews dictate new speed restrictions to dispatchers. These speed restrictions are sent
daily to trains and dispatchers and may be included in a form D.
Non-structured messages
A number of different situations can arise in railroad operations when a dispatcher must
issue verbal permission to a roadway worker. For example a signal worker needs verbal
permission to put an interlocking in local mode or to temporally shut it down. These verbal
permissions don't always follow the same pattern and are not very common.
Another type of interaction between dispatchers and roadway workers occurs while the latter
ones are already working under protection. Dispatchers usually ask work crews about details on
time restrictions. How long will it take to remove equipment from the track is a frequently asked
question. Also, dispatchers usually ask for details about job being performed on the track. It
gives them an idea about time restrictions as well as about availability of the track in case it is
suddenly needed.
If a roadway worker has trouble communicating with another railroad employee he/she may
call a dispatcher and ask him/her to send the message or make the telephone call that he/she can't
make. This is a highly situation specific interaction that does not occur very often.
3.1.2
Actions and cognitive processesperformed by dispatchers and roadway workers.
In this section, we give a description of the different groups of roadway workers that interact
with the dispatchers. The actions that dispatchers and roadway workers perform are also
summarized.
22
Different people who interact with the dispatcher
Description
Operator/Equipment
Bridge operators.
They are not roadway workers, but their effect on the dispatcher is
very similar. The bridge operator calls the dispatcher if there are
ships that require the bridge to be opened. The dispatcher unlocks
the bridge (it is shown as if occupied by a train on his/her terminal)
and control is given to the bridge operator. The bridge has to be
locked again if the dispatcher wants to use it for routing operations.
Electrification workers.
They call the dispatcher for protection, but this interaction rarely
happens because of the existence of the point conductor. The
interaction is very similar to that one with the point conductor.
Flagman/Conductor.
Asks for foul time or form D's to protect repair crews of roadway
workers or contractors.
Sometimes freight trains are like work extra trains from the point of
Freight trains.
view of the dispatcher. They report tons carried, number of cars
(loaded/empty) and engine number.
Handles all the foul time requests within a large section of track.
Point conductor.
The point conductor was introduced in the northeast corridor
because of the electrification project that was a stepping stone
towards the high-speed service. The point conductor was intended
to be the only one in the area under his responsibility who interacts
with the dispatcher.
Asks for permission to shut down signals or to put them in local
Signal worker.
mode.
Track car foreman.
Asks for permission to operate a track car and to pass stop signals.
Work extra train crew.
The information shared includes: details of equipment left on the
track, new speed restrictions sent to the dispatcher and directions to
the dispatcher about how to route the train. They decide where they
want the train to be and they ask the dispatcher to perform the
necessary switch changes.
Table 3-1 Roadway workers that interact with dispatchers
23
Actions performed by dispatchers
When a dispatcher receives a request for protection form a roadway worker he/she usually
follows the same steps.
Right after the request has arrived, the dispatcher undertakes a decision process. He/she has
to decide whether or not to grant it. With experience this thought process does not usually last for
a long time and the main decision aid is the schedule and the current delays of the trains.
Assuming that the dispatcher has granted permission to work (under foul time, form D or
verbal permission) he/she must block the track where the roadway worker is going to be. At the
Traffic Control Center, blocking a track protects the roadway worker since it prevents the
dispatcher to route trains on that track. At the job site, it is like applying a blocking device (see
glossary) to the switches and signals that control access to the blocked track. Operation of these
switches will be restricted and the blocked track will show stop signals in both ends in such a
way that no track vehicle may enter it. Once a track is blocked, the dispatcher loses authority
over that track. The dispatcher won't be able to reverse or normalize a switch that is part of the
blocked track. If a roadway worker wants to change the state of a switch, he/she can do it either
by using the switch local mode (this can be done without dispatcher authority since the roadway
worker owns the track) or by calling the dispatcher and asking him/her to do it. This is a very
common request. Dispatchers have to unblock the track, reverse or normalize the switch and then
block the track again because it still is under the authority of the work crew.
While the roadway worker is doing his job, he/she may interact with the dispatcher. These
interactions include further permissions, speed restrictions submitted by work crews to the
Traffic Control Center and mostly updates on train location.
Once the job is done and the roadway worker gives the track back to the dispatcher, it has to
be unblocked.
There are other types of dispatcher actions that have no direct relationship with roadway
workers but, to the eyes of the dispatcher, they receive the same consideration. This is the case of
locking or unlocking bridges (like blocking or unblocking track) or letting special equipment
such as extra trains operate in their territory.
24
For a more detailed explanation of the actions performed by dispatchers see Roth, E.M. and
Malsch, N., 1999.
Actions performed by roadway workers
According to the instructions given in the Roadway Worker Protection Class whenever a
roadway worker wants to perform a job in the track, he/she needs to go through the following
steps:
1.
Collect information.
*
Identify milepost number.
" Identify track numbers.
" Identify the type of territory.
*
Identify what dispatcher controls the territory.
" Find out train schedule around working site.
2. Conduct a job briefing with entire crew.
3. Call for foul time or form D when necessary.
4. Give the track back to the dispatcher on time.
5. At the end of the tour of duty, make sure work area is safe and secure.
In step 1 of the work procedure, the roadway worker must read the schedule and territory
information from the Operating Rules book. This book only contains scheduled passenger trains.
Non scheduled trains (freight, work extras,...) and commuter trains with higher frequency are
not shown in the book. The railroad worker needs updated information about the location of all
the trains that could interfere with his/her job so he/she calls the dispatcher for schedule updates
and for nonscheduled train information.
In steps 3 and 4, roadway workers use the different types of messages discussed in 3.1.1.
Regular roadway worker tasks include inspection, construction, maintenance or repair of
railroad track, bridges, roadway, signal and communication systems, electric traction systems,
roadway facilities and roadway maintenance machinery on or near the track. There are also
roadway workers whose only duty is to protect other members of the crew. These are called
25
flagmen. Crew foremen or flagmen are responsible to obtain permission from the dispatcher
according to the steps described above and they have to follow these steps regardless of the job
they are doing.
It is worth highlighting the role that track cars play as roadway maintenance machinery.
Track cars do not usually shunt track circuits so they do not show their location on the
dispatcher's screen. Track cars need movement authority (form D lines 2 and 3) and also
authority to pass stop signals (rule 241) from the dispatcher. Other general-purpose trains,
usually called work-extra trains carry equipment and work crews to job sites. These are nonscheduled trains that effectively shunt track circuits but that may be left on the track for a period
of time. Work extra trains left on the track need form D line 4 authority from the dispatcher
Finally we must mention the drawbridges. Drawbridges have to be locked before they are
used for routing operations. If they are unlocked, the dispatcher will think of them as a track
blocked for a roadway worker.
3.1.3
Dispatcherand roadway worker comments aboutproposedtools to enhance their safety.
Apart from obtaining a better understanding about their work, another goal of the interviews
with dispatchers and roadway workers was to get some feedback about new tools that we
proposed that were aimed towards an improvement in safety. Here we present the comments we
received.
1. Electronic reception (dispatcher) and issuance (roadway worker) of work requests.
Dispatchers liked the idea of receiving requests electronically. They could browse through a
work request queue and answer each request in whatever order they considered appropriate.
As has already been noted, this fact has been confirmed in previous experiments conducted
with a train dispatcher simulator at Volpe National Transportation Systems Center (Malsch,
N. 1999).
On the other hand, roadway workers expressed concerns about training issues and security
and authentication. They did not want to type work requests into a computer and they were
worried about other people using their computer to make work requests. They saw no need
for electronic issuance of form D requests because they only sent a couple of these requests
per day.
26
2. Electronic reception (roadway worker) and issuance (dispatcher) of work permission.
Dispatchers liked the idea but only if they didn't have to type any information. If they had to
type, then they saw no difference between written and electronic Form Ds. Other benefits
were time saving, legible form Ds and verification system that could be implemented to
protect from certain types of human error such as blocking a track that does not match the
one given in the work permission. Some disadvantages mentioned were losing the
opportunity to interrupt somebody during the work request procedure and difficulty to deal
with acknowledgements. Confirmation that the correct message has been received is of major
importance to dispatchers and they expressed their concern about whether the currently well
establish procedure of acknowledgments could be replicated using electronic media.
Roadway workers felt no need for this tool. If they would not use an electronic device to send
the work request they would neither use it to receive the work permission.
3. Automatic generation of train schedule including current delays.
Roadway workers really liked this idea. They said that it would be useful because what they
required was more specific information about train location. The tool would be really useful
if the schedule included all the trains that were on the track, not only the scheduled ones.
3.1.4 Human-machine interface.
Roadway workers did not like the idea of carrying a laptop computer. As it has been said in
the previous section, they were concerned mostly about training issues, about the fact that some
of them were not used to computers and about security and authentication. Roadway Worker
Protection (RWP) class instructors helped to obtain a set of conceptual specifications of an
electronic portable device that could be used by roadway workers.
They depicted a portable device like a pager, a palm device or a cell phone where updated
information of train location (only to the level of last interlocking reached by a train) could be
received. This device would be much easier to use than a laptop computer. They said:
"Information about train location is already there, why don't we share it with the ones that will
make good use of it?"
27
Some of the features of this handheld device could be:
" Automatically generated timetable, including delays, of the trains that are supposed to arrive
at the location where the roadway worker is performing a specific job.
*
Nearby trains warning. Track blocks are usually several miles long, so whenever a train
enters the same block where the roadway workers are or the one parallel to it, this device
could send them a warning.
"
Simple user interface. Common requests, such as where this train is or what is the next train
at this interlocking, should be very easy to initiate.
" Knowledge about the time they can ask for foul time or the time they have to wait before
asking for foul time.
3.1.5
Conclusion of the pilot study
According to the results of this study and with the idea of increasing safety in roadway work
operations by improving the communication between dispatchers and roadway workers we
proposed the system shown in Figure 3-1. The highlighted solid box represents the main part of
the system: the roadway worker Personal Information Device (PID).
Note that although oral communication is not included in Figure 3-1, we do no intend to
eliminate this type of communication. It has only been removed from the figure for clarity
purposes. Also, note that, despite the concerns about using an electronic device to send work
requests, we have decided to include them in the system. The reason is that when the electronic
issuance/reception of work requests/permission was described to roadway workers, it was
assumed that a laptop, not a handheld device, was going to be used. As we mention below, the
current PID prototype ran on a handheld device that was much simpler to use than a laptop.
This prototype had a set of pre-programmed requests that were filled without typing by the
roadway worker so the problems about typing information into a computer were avoided.
There were two major types of requests.
" Database requests.
" Dispatcher requests.
28
User interface: User sends a
request without typing and PID
returns the answer whenever it is
available
Roadway worker
Personal Information Device PID
Database requests
1.
2.
1. Train status
Dispatcher requests
Form D / Foul Time
requests
Cancel work
permission
2.
3.
4.
5.
6.
I
I
Dispatcher's
terminal
Train schedule around
working site
Territory info
Track out of service report
Form D / Foul Time under
the authority of user
More...
Train Schedule
Database
Automatic
update
User Interface: Dispatcher
receives and answers
requests using a web page
interface
User interface:
Manual update using
a web page
Train Schedule
Database
Manager
Dispatcher
Human operator
===
Data link
Electronic device
4
Interface
Figure 3-1 Proposed functionalities of the PID
A computer that looked into a train schedule database and automatically sent the response to
the roadway worker answered database requests. On the other hand, a human operator
(dispatcher) must handle requests that were related to work permissions.
The PID included several automated functions that had the potential to improve safety and
efficiency. Here we highlight the issue of how far should we automate. We didn't try to automate
every function that could be automated. There were some risks on this approach. Basically we
were proposing a new set of automated tools that didn't override the current radio and phone
29
communication system but provided much more information to the work crews while, at the
same time, improved dispatcher efficiency.
3.2
Prototype design
3.2.1
Alternatives
We were looking for a device that could be used from any point along the track. We
considered the following devices:
" Laptop computer with modem and cellular phone to obtain connection to the Internet.
" Pager or cellular phone.
" Handheld device.
Although a laptop introduced great flexibility in terms of features that could be included in
it, soon after the conclusion of the pilot study we rejected this idea. Not only it was too big to be
carried by a roadway worker but also other more important issues of acceptance made the laptop
a risky option.
A pager or a cellular phone would have been a good idea. They had good wireless coverage
along the track and roadway workers were used to them. Although any of these devices could
receive information, at the time that the selection had to be made, they were hard to program in
order to use them to send requests to a computer.
A handheld device such as a Personal Digital Assistant (PDA) was considered. Because of
the excellent support for developers given by Palm Computing Platform, we selected a palm
device. The initial idea was to use a Palm IIIx or a Palm V with a cellular modem to obtain
connection to the Internet, but in early 1998, the Palm VII device became available. The reasons
explained in the following section made it a good prototype for our purposes.
3.2.2
Palm VII: Advantages and disadvantages.
The Palm VII device (Figure 3-2) was the latest member of the 3Com family of handheld
organizers. Some of the features of the Palm VII were (see Palm VII white paper web page):
0
Pocket size: 5.25" x 3.25" x 0.75" and light weight: 6.7oz
30
" Built in wireless Internet connection with security measures (data encryption, secure
sockets layer, network authentication,...).
" Weeks of battery life on two AAA batteries (depending on usage) and low battery
indicator.
"
Send and receive email.
" No previous computer knowledge required. Worked with a pen that is used to tap on the
screen and fill the requests without typing.
*
Infrared port that could be used with a portable printer.
Its weight and dimensions together with the wireless Internet capability made this device a
good prototype for data link communications with roadway workers.
Figure 3-2 Palm VII
The main disadvantages of the Palm VII device were its fragility and the fact that it couldn't
receive information without first asking for it. It had two way communication capabilities but the
communication had to start always at the Palm VII side. Its fragility made the Palm VII useless
in tough environments such as the railroad. It didn't resist rain or dust and it was hard to read
31
under very sunny conditions. The fact that it couldn't receive information without first asking for
it made the Palm VII device useless to receive warnings (i.e. approaching trains).
As it will be explained in 3.2.4, the prototype PID system architecture was based 85% on the
Internet and 15% on the handheld device with wireless access to the Internet. With some changes
to the system architecture and page formatting, the PID could run on any handheld device with
wireless access to the Internet. Note that some of the Palm VII features (mainly authentication
features and printing capabilities) might not be available in another device. At the time the
decision was made, the Palm VII was the device that best fitted the PID requirements. At the
time of this writing, Neopoint (www.neopoint.com) has its Neopoint 1000 phone with access to
the Internet. It is a device that should be considered for future prototypes because it puts in only
one device both the PID as it is described in this project and the cell phone that most roadway
workers actually carry. Qualcomm (www.qualcomm.com) is a licensee of Palm operating system
and it now has the Pdq Smartphone that combines the benefits of a cellular phone with access to
the Internet using a Palm OS interface. Motorola (www.motorola.com) has also an interesting
catalog of products (phones and pagers) under the category they call "web without wires".
3.2.3
Palm VII: Security, authenticationand training.
As we saw in 3.1.3 these three issues were a major concern for roadway workers. In this
section we explain how security, authentication and training were taken into consideration with
the Palm VII device.
Regarding security of messages against external agents, the palm VII incorporated different
levels of protection. During the wireless portion of the communication, the Palm VII used a
cryptographic technology developed by Certicom. According to the product white paper (Palm
VII white paper web page) "Certicom's advanced elliptic curve cryptosystem enables
significantly shorter message sizes with the security strength of their 163-bit keys. These keys
are equivalent in strength to RSA 1024-bit keys, thus minimizing message lengths without
sacrificing security". During the server to server portion of the communication, between the
Palm Computing Web Clipping Proxy and other servers, 128 bits secure socket layer (SSL)
could be used. There were also other levels of security such as network authentication and
physical security of the Palm Computing Web Clipping Proxy server.
32
Regarding authentication, two different levels could be provided. Each Palm VII device had
a built in device ID that could be sent with every message. We used this device ID to identify
which roadway worker was sending each request. Also, messages from Palm VII devices that
were not registered with the PID system were ignored. No unregistered user was able to retrieve
train location information or to submit a work request to a dispatcher. The second level, which
was not incorporated in the prototype, was password-protected access to the system. A personal
password could have been required to communicate with the Traffic Control Center.
Regarding training, special attention was paid in the design of the user interface of the Palm
VII. As it will be shown in the results of the experiments, users with no prior knowledge of palm
devices or computers demonstrated good acceptance of the user interface.
3.2.4
PID system architecture.
As we can see in Figure 3-3 the PID system architecture developed in this project was
heavily based on the Internet.
The PID prototype ran on a Palm VII, a small information appliance with wireless access to
the Internet. The PID sent and received information to a web server. Running on the same
computer as the web server, there were a number of query servers that were looking for requests
sent by the PID, the dispatchers or a database manager. These query servers were the core of the
system and they were responsible to redirect the request to the appropriate dispatcher when the
request was a work permission or, when it was possible, to answer the roadway worker without
distracting the dispatcher by looking into the database.
Dispatchers interacted with the system via an interface of web pages. Through this interface
they received work requests from roadway workers and sent work permissions.
The database contained information about train schedule in the past, expected schedule in
the future, current delays, train information, out of service track under form D or foul time and
territory information (maximum speed, dispatcher in charge, rules that apply). In the PID
prototype developed in this project, the database was modified manually by a database manager
using another interface of simple web pages.
For a more detailed description of the PID system architecture see Appendix A.
33
/0
A
Base station
/
PID
The Internet
Dis patcher interface
Database manager ir iterface
Web Server
Database
Query servers
L
------
-
--
--
----.
Figure 3-3 PID system architecture
34
Experiments
3.3
3.3.1
Overview
The goal of our experiments was to identify features that the new communication system
with data link technologies must have before it is even considered for use in real railroad
operations. Also we had to identify potential side effects (i.e. changes in workload or safety
concerns) and degree of acceptance of such a communication system among roadway workers.
We did not pay special attention to the specific device that we used. We had to find the
underlying principles that any wireless device had to have before roadway workers used it in real
railroad operations.
3.3.2
Early tests
During the early steps of the PID design we were in close contact with the same roadway
workers that had made suggestions about it during the pilot CTA. When we had the first version
of the PID, we loaded a static database of trains, set an 'automatic' dispatcher to reply work
requests (always affirmatively) and we took the PID to the field and let the Railroad Worker
Safety class instructors use it for a while.
In this first version we had included train location and territory information and limited form
D's request. The main menu looked like Figure 3-4.
4
02MCM!
Train and territory
information
Train sch(work site)
Train sch (ID)
Territory Info Next Train
Submit work request
Foul Time
Form D
Reports
My Form Ds - My Foul Time
Speed restrictions
Submit speed restriction
Figure 3-4 PID - Main Menu (early version)
We had plans to include foul time requests and speed restrictions submission.
We received very useful comments about new features that had not been included in this
first version but that were useful in real railroad operations. As the result of these comments the
35
Next Train (next train at a given interlocking) option was removed since it was redundant with
Train Schedule at Working Site (train schedule at a given portion of track during a given time
period). A Train Status request option (general information about a train such as last and next
interlocking, time at these two locations, direction of travel and delays) was included. Some
modifications were made to the process of requesting a form D and two more options about
current track out of service and a way to cancel or fulfill a form D were included. Foul time
request procedure was discussed and according to the comments received it should have a similar
process as a form D. For the sake of simplicity in the first prototype, speed restriction submission
was removed.
After this early test, the main menu looked like Figure 3-5.
C
E
4
Train and territory
information
Train status Territory Info
Train OS (work site) Train OS (ID)
Form D
Request Line 4
Request Lines 2,3
Cancel(
My Form DsE
Track Outage
Foul Time
Request Foul
Time
Cance,
My Foul Timer
Track Outage
Figure 3-5 Main Menu (after early tests)
The next step was to show the new version of the PID to the manager of operations at
Boston's South Station and ask for his support to conduct the experiments. He was very pleased
with the device and he even saw more applications apart from the PID being used only by
roadway workers. He liked the idea of knowing from anywhere at anytime about the
performance of the railroad network. It could be used from the management point of view to
make decisions or to keep track of the state of the network.
3.3.3
Laboratorytests.
After these early tests, we conducted more formal experiments in the laboratory. We used a
simulated train schedule database (see A. 1.4) that included all Amtrak trains from Boston to New
Haven, some MBTA commuter trains and some unscheduled work extra trains. The delays of
these trains were initially set to predefined values.
36
Two series of laboratory tests were performed.
" Usability test.
"
System evaluation test.
The first one was a pure usability test. Although our goal was not to have a perfect user
interface but to evaluate the communication system, we wanted to be sure that the users would
have the ability to complete tasks using the prototype. A quick usability test with a small number
of users was performed, and some modifications were done to the user interface according to the
results of this test.
The system evaluation addressed the questions that were of importance to us as the goal of
the project.
Participants
The individuals that participated in the experiment as test users were actual roadway
workers whose duties were related to the section of the North East Corridor that goes from New
Haven, CT, to Boston, MA. For this reason, the prototype contained the names of the stations
and interlockings that belonged to this territory.
Three roadway workers participated in the usability test and six in the system evaluation
test. Out of the nine test users, one was female. They were all conductor flagmen. Average years
of experience in the railroad were 16 ranging from 1 to 37 years. They received compensation
equivalent to a full day of labor. The average rate per hour was $21.
Their most noticeable interactions with dispatchers were 34 foul times per week, 5 form D's
per week, 17 train status requests per week and 5 Train Speed Restrictions Bulletins per week.
We also asked about their background in communication devices and services. They were
all very familiar with radios, familiar or very familiar with PC's, pagers, cellular phones, WWW,
and e-mail and all but one were unfamiliar with palm devices.
37
Usability test
Purpose: Evaluate user's ability to complete the tasks effectively.
Users: 3 roadway workers.
Materials: One Palm VII device.
Procedure:
" Training: Users were briefly trained during 30 minutes. The steps to complete each task
were explained. All questions were answered during training session and they were
annotated as well.
" Task conditions: User operated the Palm VII device. The test was recorded in audio tape
and the user actions were stored in a file.
" Task: A list of tasks was assigned to the user. The user carried out each task while
"thinking aloud". The tester did not answer questions unless the user was stuck and not
able to go any further. The tester asked the user questions, especially when the user was
not saying anything.
" Questionnaires: At the beginning of the test we asked about demographic information
such as years of experience and background knowledge of data link devices. During the
test, we asked usability questions about both groups of requests (database and
dispatcher). At the end of the test we asked miscellaneous questions about PID
improvement, task realism and how the information was presented to the user (font sytle,
size, navigation procedures ... )
Elapsed time: 30 min for training, 3h for tasks and questionnaires.
Observations and measurements:
From the recorded comments we could identify points of bad user interface, points where
the user was confused and did not know how to proceed, and errors made while using the device
(i.e. selection of wrong menu).
38
From the questionnaires, we captured subjective measurements about usability of the device
(in terms of rating scales) as well as comments about PID improvement and potential changes in
the way that the work request procedure was handled.
From the log files, we captured the number of times each feature was utilized, how did the
test user recover from errors and, with less importance in this experiment, the time it took to
complete each task.
Experiment setup:
Computer to
receive task
instructions
Test user
PID
Microphones
Computer to answer
work requests
(Dispatcher interface)
Tester
I
Figure 3-6 Usability test, setup.
System evaluation test
Purpose: The purpose was to find the underlying principles that any wireless device had to
have before roadway workers used it in real railroad operations. We had to identify must-have
features, potential side effects (i.e. changes in workload) and acceptance
of such a
communication system among railroad workers. We took some measures of wireless device
efficiency.
Users: 6 roadway workers.
39
Materials: One Palm VII device. Two radios (one for the tester). Worksheets to write down
the information that the test user considered appropriate. Book of operating rules, Amtrak
schedules and public MBTA schedules.
Procedure:
*
Training: Users were trained on all the features of the device. They used the device on
their own until they felt comfortable with its operation. All questions were answered
during the training session.
*
Task conditions: User operated the Palm device and the interactions were stored in a file.
When the radios were used, all the conversation was recorded on audio tape.
*
Task: Two lists of tasks were assigned to the user who carried out one group of tasks
with the PID and the second group of tasks with the radio. In either case, the tasks were
presented by a computer and only after the previous one had been completed. Tasks
were independent and at different simulated times. Some tasks could not be
accomplished (because of train schedule conflict for example), so the user had to
identify the problem and report it.
After 6 test users took the test, each group of tasks was handled 3 times with both the
PID and the radio.
*
Questionnaires: At the beginning of the test we asked about demographic information
such as years of experience and background knowledge of data link devices. During
each group of tasks we stopped the test twice to ask situation awareness questions. At
the end of the test we asked questions about PID usefulness, PID improvement, overall
comfort level using the PID, task realism, changes in workload compared to current
communication system, and principles that must be addressed before the PID was used
in real railroad operations.
Elapsed time: Average times were lh:10m during training, lh:32m during PID test, 1h:04m
during radio test, plus another hour explaining rules of tests and answering questionnaires.
40
Observations and measurements:
From the three sources of log records (worksheets, files when the PID was used and audio
tape when the radio was used) we could measure the time spent during information gathering,
work permission request and work cancellation. We also took measures of errors made by
roadway workers. These errors include work requests that should or should not have been sent,
communication errors and errors that compromised safety. These measures are explained in
greater detail in section 4.
From the questionnaires, we captured measures about situation awareness in terms of the
trains noticed by the roadway worker as potential hazards during his/her job as well as type of
territory (i.e. maximum train speed). We also captured subjective measurements about
acceptance of the PID or a similar device and changes in workload (in terms of rating scales),
comments about PID improvement, safety concerns, other potential uses of the PID and task
realism.
Experiment setup:
Computer to answer
work requests
(Dispatcher interface)
Computer to
receive task
instructions
Test user
PID
Tester
Radio
__
Radio
Figure 3-7 System evaluation test, setup.
41
_
Microphone
4 Results and Discussion
From the usability test, we found out that a few changes had to be done to the PID user
interface before we conducted the more formal system evaluation test. The most important one
was to change the last steps of the foul time request, which turned out to be confusing for the test
users. We applied the same modifications to the Form D request to retain consistency. Apart
from this change, minor revisions were made such as uniform use of am/pm time format,
rewording of buttons and menu titles, easier access to the main menu and additions to
information sent with the train status report.
From the usability test we also learned that although the font size and the overall device size
could be larger, the information was presented in a readable and very organized way. The PID
menu structure was fairly easy to navigate, except when the use of the vertical scroll bar was
needed, and it was designed according to current railroad operations needs. The screens used to
generate and send requests were very complete, easy to understand and moderately simple. At
the same time, the screens reflected very realistically railroad operations needs and helped the
user introduce the required information, which was a moderately easy task. Despite all this, these
screens were somewhat slow. The information received at the PID as the result of a request for
train or territory information was expected and abundant.
Once the changes mentioned above were made, based on the acceptance of the overall
system architecture, we carried out the system evaluation test.
Measures taken and method of analysis.
4.1
The specific measures taken during the system evaluation test were:
Time measures
" Time to complete a task. It included all the time since the test user received the task
instructions until he or she went to the next task. Instructions and test user actions were
always paired and decoupled in time.
*
Time to complete a work request or a work cancellation. It included all the time since the
request was initiated until it was completed and acknowledged. These times were easily
obtained for the radio case by listening to the recorded tape. When computing these
42
times using the PID we had to make an approximation. Since the log files only stored
request information when they arrived to or were sent form the web server, we did not
know about the actual time when the roadway worker started to fill the request or the
actual time when the answer finally arrived to the PID. This is why, for each work
request, two approximate times were added to the ones stored in the log files. These
times were an average time to fill a work request form and twice the average time it took
for a packet to arrive from the PID to the web server (network latency). These average
times had been computed for each screen in the PID. It is worth mentioning that the
network latency was as low, for a wireless device, as 5 seconds.
Error measures
Four different types of errors were considered:
*
Work requests that should have been sent. The roadway worker had the opportunity to
send the request but for some reason he did not send it.
*
Work requests that should not have been sent. These were work requests that, because of
traffic conflict, should not have been sent or work requests sent to the wrong dispatcher
when using the radio.
*
Communication errors. These were work requests sent more than once when using the
PID, work requests sent with incomplete description or that had to be repeated over the
radio.
*
Safety errors. These involved work permissions accepted without knowing about traffic
patterns during the period the work lasted, work permissions that were not cancelled
when it was required or work permissions accepted in a location that was not the one
requested.
Except for the work requests that should have been sent, where the correct amount was six
for the first set of tasks and seven for the second, all error measures were considered as absolute
values. Since one test user did not take the test with the radio, the absolute results for his errors
during the test with the PID were not taken into account in the analysis.
43
Situation awareness measures
Two sets of measures of situation awareness were taken. The first one involved information
(territory information and traffic patterns) about the work site that, at some point, was read or
retrieved by the test user. The second test involved the same type of information that was
remembered by the test user when he or she was asked about it.
" Territory information included dispatcher in charge, maximum train speed and rules that
applied in the section of track where the work took place.
" Train information included the relevant trains that affected the roadway worker during
the time when the work took place. The roadway worker was required to know about the
train ID, its updated schedule, whether or not the train was delayed, and its direction.
The method of analysis for the situation awareness was based on the specific window of
time of each task. The trains that were supposed to pass by the work site while the job was
performed were the basis of the grading scale. If the roadway worker knew about all these trains
he received a score of 100%. Otherwise, the score was computed according to the amount of
information he knew versus the amount of information he should have known.
Other measures
As it was mentioned in the description of the system evaluation test, we also captured
subjective measurements about acceptance of the PID or a similar device and changes in
workload (in terms of rating scales), comments about PID improvement, safety concerns, other
potential uses of the PID, and task realism.
Difference between radio and data link communications.
4.2
4.2.1
Data link device results in safer operations.
We can say that the data link device resulted in safer operations from two different points of
view.
First, the situation awareness was much higher using the PID device than the radio.
Considering the train location and territory information that a roadway worker must collect
before he or she performed a job on the right-of-way (see section 3.1.2), test users received more
44
information and with greater accuracy using the PID device. Alternative sources of information
when the roadway workers used the radio were the MBTA commuter train public schedules and
the NORAC operating rules book that contained both schedules of Amtrak trains and territory
information. They could call the dispatcher by radio for updates on train schedules.
As Figure 4-1 shows, of all the information they were supposed to collect, they did a better
job when they used the data link device
100. 0%
Amount of information retrieved
99.7%
83.9%
99.7%
9.7*
80.0%
62.5%
60.7%
0.70
60.0%
38.3%PID
40.0%
670
20.0%
0.0%
Territory
Info
Relevant
Trains
Train
Updated Train delay
direction
Train
Schedule
Figure 4-1 Information retrieved
"Territory information" included train dispatcher in charge of the territory in which the work
site was located, the rules that applied in that territory and the maximum train speed around the
work site. "Relevant trains" were all the trains that represented a potential hazard for the work
crew, this is, trains that would go by the track adjacent to the work site while the crew was
working. It is worth mentioning the difference between "Updated train schedule" and "Train
delay". "Updated train schedule" refers to the fact of knowing the real time train schedule with
any possible updates, while "Train delay" refers to the fact of knowing whether a train is delayed
or not. If train 012 was due at View at 9:45am but it was 10 minutes late, knowing that it would
reach View at 9:55am was a point towards "Updated train schedule" and knowing that it was 10
minutes late was a point towards "Train delay". Knowing the train delay immediately guaranteed
knowledge of the updated train schedule, but not the other way around since when they used the
PID they didn't have access to the printed schedule to make comparisons. The PID always
45
displayed updated times but the train delay had to be retrieved in a specific screen that was not
often visited. When roadway workers used the radio, they could radio the dispatcher for updates
but they did not take advantage of this opportunity. This could be explained because in the real
world, roadway workers tend not to bother the dispatcher with this type of request. They usually
find out the train status (updated and relevant information about a train) by calling directly to
stations or to other crews in the track. The dispatcher is the last resort they use when they want to
know a train status. They suggested that information about train status should be integrated with
information about train schedule. Had this integration been included in the PID prototype, the
train delay for the data link device would have had the same level of knowledge as the "Updated
train schedule".
"Train direction" had the same magnitude as "Relevant trains" since the train ID number
parity gave its direction. We learned that this is not the rule for work extra trains (unscheduled
trains used in maintenance operations) but this detail was not included in the simulated train
schedule database.
Compared to the radio, we were expecting better results for the data link device. It was
reasonable to think that using the paper source of information a train could easily be overlooked.
On the other hand, we thought that the data link device would provide too much information that
would result in less memory retention. This is why we introduced a set of situation awareness
questions in the tasks. These questions were asked immediately after a work request had been
processed and they were aimed to measure whether the information retrieved by PID was
remembered or not. In a similar way to real railroad operations, test users were required to write
down in a worksheet the information they considered relevant to their work, but they were not
able to use these worksheets when answering the situation awareness questions.
Figure 4-2 shows that, against our initial assumption, roadway workers tend to remember
more of the information that is retrieved using the PID device than that retrieved by radio or
from printed schedules.
The second fact that supports the statement that the data link device results in safer
operations is the number of safety errors. With radio, the test users made more than five times
the safety errors they made with the PID device.
46
Amount of information remembered
8
100.0%
9'.o
87.5%
81.80/(72.9%
80.0% .__
60.0%
7.5%
60.0%
P ID
Radio
40.0%2
20.0% .
0.0%
Window of
time
Territory Info
Relevant
Trains and
direction
Train delay
Figure 4-2 Information remembered
Figure 4-3 shows that, while the amount of work requests that should not have been sent is
similar for both radio and data link, there were 11 safety errors with the radio and only 2 with
data link device. A work request that should not have been sent could be understood as a risky
situation, because either the roadway worker wanted to work when there was traffic that
prevented it, or he or she was not aware of what dispatcher was responsible for insuring his or
her safety. The vast majority of safety errors came from the fact that test users accepted
permission to work without being fully aware of the future traffic conditions during the job.
Errors
14
12 ._11
10.
8
.
__________
6.
PID
4.
4
.4
*Radio
3___
2
2 ,M
Work requests that
should NOT have been
sent
Safety errors
Figure 4-3 Safety errors and wrong work requests
47
4.2.2
Data link device results in better knowledge of potential risks but in reduced number of
jobs completed.
As was mentioned in the previous section, the data link device resulted in better knowledge
of potential risks for roadway workers. At the same time, while resulting in greater risk
awareness, the use of the PID produced fewer jobs completed. Figure 4-4 shows the relative
number of work request sent during the experiment. A 100% would mean that all the requests
that could have been sent were actually sent, but we see that with the PID fewer work requests
were sent.
100%.
80% .
88%
77%
PID
Radio
60% 40%
20%
0%
Work requests that
should have been sent
Figure 4-4 Work requests sent
It is worth mentioning that half the work requests that were not sent for both the radio and
the PID came from the same test user. This test user had very little experience in the real world.
He had submitted less than ten form Ds to real dispatchers. This could explain his reticence to
submit work requests. Not taking this test user into account, 93% of the work requests would
have been sent over the radio and 84% with the PID. This less experienced test user was also
among the ones with higher situation awareness. This fact also supports our conclusion that the
higher the knowledge of potential risks the lower the number of jobs completed.
48
4.2.3
Communication seems to be slower but more accurate using the data link device. The
workload remains the same.
Figure 4-5 shows average completion times for successful interactions between roadway
workers and dispatchers. We can see that it usually took longer to request both a form D and a
foul time using the PID. In real railroad operations a foul time is not as structured as a form D
and it usually is much faster to obtain. This was reflected in the radio tests but not when the PID
was used. With the PID the foul time request procedure had fewer steps than that of the form D
but the steps removed from the foul time procedure were quite fast and didn't affect significantly
the time it took to request a foul time.
The cancellation of a work request was very short when the PID was used and it was
comparable to a foul time cancellation over the radio. The form D cancellation took longer over
the radio because the acknowledgment steps required reading twice the main fields of a form D.
4:00
3:30
3:00
2:30
Average times
3:30
3:05
2:26
2:00
OP
P1:28
ID
1:30
1:12
1:00
Radio
0
0:30
0:00
Form D
request
Form D
cancellation
Foul time
request
Clear foul time
Figure 4-5 Average times for successful interactions
It is worth mentioning a factor that affected all these times and that was not taken into
account. During the tests, the dispatcher tried to answer as fast as possible the work requests. In
real operations this is far from being true. Dispatchers are often busy with other tasks and do not
answer the requests right away. Also, we should say that all the test users declared themselves
very familiar with the radio. Some of them had more than 15 years of experience using the radio.
Except for one test user who had prior experience with the palm all the others were very
49
unfamiliar with palm devices. In fact, they only had around 1 h: 15m of training but as one test
user said during the usability test "The more I worked with it, the more understandable it
became."
Because of the structured way of asking for work protection when the data link device was
used, the test users made fewer communications errors with the PID. They always had to fill the
same fields and it was harder to forget about one of them. The communication errors with the
PID could have been reduced to almost none if the Palm VII had had the ability to verify the
request before it was sent to the dispatcher, but Palm VII did not support the required JavaScript.
10
9
8
6-
-
PID
*Radio
5
4
2
0
Communication errors
Figure 4-6 Communication errors
The less constrained radio environment resulted in more communication errors, but at the
same time, its flexibility allowed a faster error recovery so more errors did not result in longer
times.
Despite the fact that it took longer to obtain work protection and that errors were expensive
in terms of time with the PID, the test users did not feel a change in workload. This could be
explained because it was easier to retrieve train and territory information. As one test user put it,
"after using the device it was hard to go back to the printed schedules".
50
4.3 Potential implementation of a data link device in railroad operations.
4.3.1
Favorableacceptance of the data link device, with some conditions.
Test users were asked if they would use the PID in real railroad operations. To show that the
PID could be used to retrieve train and territory information or to ask the dispatcher for
protection or for both, we asked two separate questions. Still, the acceptance was excellent in
both cases. In a scale form 1 to 5 where 1 is maximum acceptance, the test users rated the PID
with a 1.2 to retrieve train location information and with a 1.5 to ask the dispatcher for
protection.
But the acceptance not only was shown in these two questions. The attitude of the roadway
workers when they tested the device was highly positive, and they liked the fact that without
long training they were able to operate the device without assistance. Three of the test users
directly asked the question of whether they would get a PID if it was to be used in real railroad
operations. Almost all of them saw other potential uses, discussed bellow, for the PID and one of
them even saw commercial opportunities for it. As one roadway worker said "[The PID] is an
excellent tool for employees working both in the right-of-way and for employees working on
trains".
Despite the positive disposition to use the PID in real railroad operations, test users
mentioned a list of features that it must have before introducing it in their daily work. Identifying
these conditions was one of the goals of the project. They are discussed in the following section.
4.3.2 Features that a data link device must have before it is introduced in real railroad
operations.
When asked about "must-have" features for the PID device, the roadway workers mentioned
the following ones. We have separated these features into two categories: hardware requirements
and software requirements
Hardware requirements
The wireless device must be waterproof, shockproof and maybe have a clip and a hardcover.
It should be larger, less fragile and able to do a self-diagnostic test to assure screen accuracy (i.e.
to find pixels malfunctioning that may cause incorrect readings).
51
The battery life should last at least one full day. The batteries of the Palm VII easily lasted a
few days but the transmitter had to be recharged after prolonged wireless transactions. The Palm
VII user did not realize this need for recharging because it took place during the night, but if the
charge was really low, the Palm VII was not able to conduct wireless transactions for at least 50
minutes. This is unacceptable for real railroad operations.
The wireless coverage should span the entire right-of-way and its surroundings. Test users
were concerned about this issue because cellular phones, that used a similar technology to that of
the Palm VII, had dead spots along the track.
It should allow two-way communications so warnings could be received at the PID. The PID
should also warn the user about approaching trains whenever they entered a block close to their
working sites.
Software requirements
The system must keep a log of old work permissions. NORAC rules establish that Form D's
have to be kept for a period of time. Also, roadway workers usually keep a log of their foul times
and they would like the PID to do that for them.
The system should not let the dispatcher grant work permission with different information
than that initially requested by the roadway worker, i.e. the system should not let the dispatcher
grant work permission on track 1 if the roadway worker requests permission to work on track 2.
For the system to be useful the train schedule database must be updated in real time and it
must include all the trains that are under the control of the Traffic Control Center. Otherwise the
PID would be a hazardous tool because they would rely on it and think that it had sent them
information about all the relevant trains.
4.3.3
Features that would improve the acceptance of the data link device but are not required
for its basic operation.
We have divided these features into three groups: improvements with respect to features that
already existed in the prototype, new features to be added and hardware improvements.
52
Improvements to features that already existed in the prototype
The software should be flexible enough to let the roadway worker ask for all sorts of work
requests. The prototype only incorporated three lines of a Form D, but there were actually
thirteen and some of them were often used and should be included, especially line 13. Also, work
requests should be more flexible in terms on the ability to describe the desired work site. In
particular, this includes ability to ask for more than one track at a time (useful when requesting to
foul an entire interlocking for example) and the ability to define work sites by mileposts limits,
not only by location names.
Before giving any section of track back to the dispatcher the system should prompt the
roadway worker for confirmation.
The train status report could be enhanced by adding the number of passengers or empty seats
on passenger trains, the number of empty or loaded cars in freight trains from foreign railroads,
and the reason for a train to be delayed.
The territory information report could include a quick reference to rules and rule updates
and a description of equipment changes (moved signals, energized sections, signals out of
service...).
The screens that showed the updated train schedule should also include a flag that lets the
roadway worker know if a train is late or on time.
The screens that showed other sections of track that were out of service under the authority
of other roadway workers should let the PID user read the work permission in effect for each
section of track.
Finally, the special trains are of enough importance to have an easier access. The prototype
had access to information about these trains, but test users acquired it only after they had gone
through several screens and had made several choices.
New features
Other movement authorities, such as rule 241, and other types of interactions with
dispatchers, such as speed restrictions, could be included. Also other relevant information such
as weather conditions in different sections of the track could be incorporated.
53
The wireless device could also be used to receive information about any situation which
could affect the safe movement of trains or their on-time performance (train speed restriction
bulletins, derailments, where the work crews or contractors may be working, blocks occupied,
over dimensioned cars,...)
Finally, the communications capabilities could be extended to let one PID user send and
receive short messages or questions, or communicate with other PID users.
Hardware improvements
Test users were specifically questioned about the need of a portable wireless printer that
they could use to make hardcopies of specific screens of the PID. The initial idea was to print
train schedule reports and work permissions. Some test users were enthusiastic about the idea
while others considered it a burden. On average, they said that a wireless portable printer was
only moderately important.
4.3.4
Other potential uses of the data link device.
All the test users were conductors, so their duties often involved being in charge of
passenger trains. This is why they mentioned the great potential that a similar device would have
on board trains. It would be useful to communicate with engineers or managers in stations while
the conductor is on the train. It could also be used to give the passengers appropriate information
about train connections or updated train schedules.
While the roadway workers are within the right-of-way, the PID could be a good tool to
communicate not only with dispatchers but also with other staff at the Traffic Control Center
such as the Trouble Desk Manager.
During the early tests, the PID was shown to the manager of operations of South Station.
From the point of view of management, he also saw great potential in the real-time train
information capabilities of the PID. By using this ability, he could maintain a better knowledge
of daily traffic patterns.
54
5 Conclusions
The purpose of the present study was to analyze what can be done at the roadway worker
side to enhance safety through data link communications. We wanted to know if the roadway
workers were ready to use new information technologies and what were the minimum
requirements that must be addressed before the roadway workers used these technologies. All
these questions were answered in this project, at least sufficiently well to guide refinement and
pilot tests in situ.
We have found that a data link device able to receive real time information about train
location greatly improves situation awareness of roadway worker by letting them know about
many of the potential hazards that they would face during their job. Initially we were concerned
about the fact that having better knowledge of train location would result in relaxation of safety.
We thought that if roadway workers knew about all the trains they would try to use shorter
windows of time to do their job and maybe even 'steal time' working unprotected. Our
experiments showed that our initial assumption was wrong. In fact, better knowledge of train
location or higher situation awareness resulted in fewer work attempts.
Also, we thought that having more information about trains would result in lower memory
retention. Our experiment showed that roadway workers tended to remember slightly more
information when they used the data link device.
The prototype that we used resulted in longer but more accurate communications compared
to the radio. We believe that the next generation of wireless devices that permits two-way
communication with the ability to initiate the transaction at both ends will greatly reduce the
time spent in work request procedures. Still, the data link prototype showed that structured
digital interactions between dispatchers and roadway workers were more accurate than the same
interactions over the radio.
Roadway workers were ready to use new information technologies. While some of the test
users already had computer experience almost all of them were very unfamiliar with the data link
prototype that we used in the experiments. Despite this fact they thought that the device was easy
or very easy to use and they were eager to implement it in real railroad operations with some
prior modifications described above.
55
Not only the roadway workers were ready to use it in typical work crew protection
environments but also they saw great potential for the data link device in different circumstances
such as on board trains or for daily manager supervision.
Roadway worker showed enthusiasm about the proposed data link device and they wanted
more features to be included in it. Available technology is ready to satisfy their needs and they
are ready to use it. There is great potential seen for data link devices to enhance roadway worker
safety.
56
Appendix A. PID System Architecture
A. 1.
Components
As it was shown in Figure 3-3, the prototype developed in this project is based on the
Internet and it has the following components:
1.
PID device. The prototype runs on a small information appliance called a Palm VII. It
has stored the web pages that are used to send requests to the dispatcher or his/her
terminal. These web pages are designed in such a way that user interaction is minimized
and simplified.
2.
Web server. Currently rail-datalink.volpe.dot.gov. This server hosts the master files that are
used as templates to send information back to the PID.
3.
Query servers. Run on the same computer as the web server and they are continuously
looking for requests sent by the PID or the dispatchers. These servers are responsible to
redirect the request to the appropriate destination.
4. Database. The prototype version is a static database but it is ready to be dynamically
updated with real time data. This database stores information about train schedule in the
past, expected schedule in the future, current delay, train information (direction of travel,
number of cars, engine number), out of service track under form D, out of service track
under foul time and territory information (maximum speed, dispatcher in charge, rules
that apply)
5. Dispatcher interface. A very schematic message console for the dispatcher. This is where
the dispatcher receives and answers requests sent to him by the PID.
6. Database manager interface. A simple web page that is used to update the database.
In this section we will include a detailed description of each of these components.
A.].].
PID device.
The prototype runs in a Palm VII, a device with wireless access to the Internet. For details
about how this wireless access is actually implemented, refer to Palm VII white paper web page.
57
It is important to mention that the Palm VII is only online whenever it sends data and it is only
waiting for incoming data after it has first sent a request. No data will be received at the Palm
VII if it has not first requested it. This fact drastically constraints the capabilities of the Palm VII.
Some design decisions had to be adapted to this constraint. The PID hosts web pages that do not
change over time and are only used to submit requests to the server.
The last version of the PID includes the following web pages.
*MI
4
Train and territory
information
Train
Trainstotus Territory Info
Train OS (ID)
05 (work site)
Form D Foul Time
Request Line 4 RequestFoul
Reeuest Lines 2.3 Time
Cancel/Fulfil
Ciegrr
My FormsW My Foul Time
Track Outage Other FoulTime
My Form D's
My Foul Time
LC
- History
TO
fictive Foul Time
0 Rttleboro-Holden
a._
I11:45o-12:15p,
-9993,
rystry
lctive Form s
lingston-Oeeiseiilm-Rmed(
Incomplete requests
-9994, Requested - Chc
Clear
Sun,
No--Nrth
own these foul times
Attleboro-Holden
Chk
Mein
, History
11.lp
11:45*-12:15p,
requests
East Corridor -
Mein Menu
4
W WA
Clear Foul Time
You
Incomplete
Cancel/Fulfill
4 - History
Cancel/Fulfill Form 0
Sun, I1.96p
You own these form Os
E 9903, North East Corridor
To
To clear a Foul Time top the errow
next toit andpress'Cler'button
Menu
(Cleer Foot TiseeL
4
History
YOU ORE NOT UNDER
DISPRTCHER PROTECTION
Sun, 11.0 1p
North East Corridor dispatcher has
received your request and the foul
time
is now clear.
will have to submit another
request if you want protection.
You
Mein Men
Table A-i PID Screen shots (1)
58
'Cancel/Fulfill'button.
nothing)
)Do
Cancel/Fulfill a Form 0 top the
arrow next to it and press
(Cennel/Felfil)
|Do nothing)
RM
4 - History
YOU RRE NOT UNDER
DISPRTCHER PROTECTION
North East Corridor dispatcher hes
received yor request and the form D
9 0003 has been concelled.
You will hase to submit another
request if you went protection.
f
main Mess
arm"
4
Train ad territory
information
Trainstatus Territoryinfo
Train OS (work site) Train 0 (1)
Form 0 Foul Time
Request Une 4
Reguest Lines 2.3
RequestFoul
ime!
Cancel/FulirlE ClearS
Me Form DE My Foul Time
Track Outa Other Foul Time
Train Status
Train OS (work site) 11
Train OS (ID)
Territory Info
-,
4
123
I1 2 3
train
schedule
Find
23
-train
status 4
Fisil more tram i~s main MehV
G&Wt
4
Train 170
Fri, 2.02p
3 hors
4
Get list of trains
Select train-10 range.
Mein Menu
Status:
On schedule
Last:
Hyde Park 1.59p
Neet
n Forest Hills 2.87p
Dletinanlens Boston
Engine Ii
1290
of cars: 3
Gat
-C
- History
000-099 100-199
200-299
300-399
400-499
500-599
690-699
700-799
000-899
900 999
-NA
Mein Was
Gt
4
-
O12 3
ohedule6
Territory information
- 96.8 Clinton
and
104.7 Saybrook
12 3
later.
4175
New Han 4.0p L.O9p
l
_4 - History
Train 05
Fri, 2.A7p
main mem
New Haven 11.0 a
New Haven 11.11a
Fair St 11.23a
Mill River Jot If,26a
Shore Line Jot 1 1.28a
Braonford 11.35a
Station
Guilford 11.43a
Get list of
Select train-D
trains
range.
|000-099|
100-199
200-299
300-399
400-499
500-599
600-699
700-799 000-899
|900-999|
pol
4
- History
- History
Train Schedule Request
Select train number:
Select train number:
w WX105
train statust)
w
Mein Moon
4
WX305
Set trainOSE
- History
Meitnes
CNL
4 - History
Train 05
Train WX1US
Fri, 2.12p
Main mene
Fri, 2.48p
Main Menu
WX305
Atwells 1.19a
Cranston 1H.25o
Oaisville 1045a
Klingston 10.59a
Station
On schedule
Lest:
Old Saybrook 1.55p
Guilford2.17p
Nent
DestinationsBranford Station
Engine #1 1775
# of cars: 6
statues
Mein Men
Table A-2 PID Screen shots (2)
59
4
- History
Territory Information
Fri, 7.5Ip
Ctbton
Weostbrook
Westbrook
& Brook
Brook &
Saybrook
Td Ms
SL 85
SL
SL
T4
T2 TI T3
562562
85 562562
85 261261261261
Main Mcny
Train Status Request
( Get
main Mtny
Find more
4 History.
Train OS
Fri, 2.13p
Main Me
884 163 BSS
New Haoen 2.09p 3.O8p 3.55p
Fair St 2.57p 3.H5p 3.52P
Mill River kt 3.02p
3 3.01p 3A.7p
Shore Line 3.0 p 2.8p
1
between:
Got itfor-matorE'
G-t 1-rinchdl
train is
Mein ses
main Mieng
- History
Territory Information
Request
i ?flpry.
To:
l
- 72.3 Hew Haven
.75.2 Shore Line Jt
between/ot:
Proe:
f
I
History
Train 05 Request
Select train number:
xlee
x1e
xI
Train
231
=T4
=m
IT "f
4 - History
05 Request
f
History
Train Status Request
Select train number:
4
Train and territory
information
Trainstotus Territory Info
Train OS (work site) Train OS (1E)
Form D Feel Time
Request Line 4 RequestFoul
Reauest
2.3
Cancel/Fulfille Clo2r
Lines
lime
MyFormDoY MyFoulTime
TrackOutage OtherFoulTime
II
Request Form D Line 4
Request Form D Lines 2,3
Form B Line 4 Request
Track
#:
Starttime:
Duration
-2
Track
Lastupdate:Fri,
North East Corridor
dispatcher has received your
respond as soon as
possible...
Please wait while dispatcher
reviews your request...
Main
Men
North East Corridor
dispatcher has received your
Press 'Check Response' button to
update this message,
(Chock PleaspontuE)
)
4
- History
Please
DISPOTCHER
M
Date: 01/2/2000
Delivered to: Oriol
D
0001
4. 2 track out of sereice betweon/at
Providence and Lawn Incharge of
Oriol
Dispatcher North East Corridor
(
4
4
- History
NOT UNDER
YOU
DISPATCHER PROTECTION
Conflict with train 093 and 8St
Dispatcher does not accept your
request and the form D 0 0002 has
been rejected.
You willhave to submit another
request Ifyou wont protection.
History
confirm Form
Rok tiwe Eff.
soon a
possible...
while dispatcher
reviews your request...
Please wait
Response' button to
update this message.
lCheckReoysonse
4 - History
2.51p Mainmenu
request and will respond as
Press 'Check
Main Menu
1
ndrequest
request and will
4
-
Metin men
4 - History
Last update:Fri, 2.51p Maein men
PROTECTION
Conflict with train 093 and 805
Dispatcher does not accept your
request and the form D0 0902 has
been rejected
You will have to subit another
request ifyou want protection.
#:
Direction: - East
- I hour (estimated)
ARE NOT UNDER
2.3 Request
Operate - 168.0 Dviille
track-car - 184.2 HtweIls
between:
l1t23am1
....................
Send rquest(
YOU
lines
Form 0
Work site - 185.1 Providence
between/at - 188.6 Lawn
Csncelpnoli(
ARE
- Hstory
Please confirm Form D 0005
Date: 01/28/2000
Delivered to: Oritl
2. Operate in East direction on 1
track between Davisvile and
Atwell$
3. Trains or track cars ahead none
TC proceed past stop signal(s) at
Dayisville
Dispatcher North East Corridor
Main Manu
(CanceoormDu
(f9ktmoEffo
4
YOU
- History
ARE NOT UNDER
PROTECTION
North East Corridor dispatcher has
received your request and the form D
# 0001 has been canceled,
You will have to submit another
request if you wont protection.
DISPATCHER
Min Metu
f
l
4 - History
Lastupdate: Fri, 3.01p MainMeu
4 - History
NOT
PROTECTION
North East Corridor dispatcher has
received your request and the form
# 001 has been cancelled.
You will have to submit another
request ifyou want protection.
YOU
North East Corridor
dispatcher has received your
and will respond as soon as
possib...
D
wait while dispatcher
assigns time effective...
Mai Mans
Press 'Check Response' button to
update this message.
Ch.chEspons
4 w History
Lost update Fri, 3.07p Maein Men
North East Corridor
dispatcher has received your
request and will respond as soon as
possible...
Please wait while dispatcher
assigns time effective...
Press'Chock Response'butnto
update this message.
Rposse6
(Chmcka
4 O History
Form 0 0003
Date: 01/28/2009
Delivered
UNDER
DISPOTCHER
request
Please
ARE
)
M=
4 - History
Form 0 0005
Date: 01/28/2900
Delivered to: Oril
2. Operate inEast direction on I
track between Dasisoille and
Atwells
3. Trains or track cars ahead none
TC proceed past stop signal(s) at
to:Lriol
4. 2 track out ofservice between/at
Providence and Lawn in charge of
Orisi
Dispatcher North East Corridor
Time Eff. 3:00p
Oslo mass
Davisyille
Dispatcher
Time Eff.
Table A-3 PID Screen shots (3)
60
North East Corridor
3:19p
Main Manu
-Train and territory
4
information
Trainstatus
Train OS (work site)
Territoryinfo
Train 05 D)
Form 0 Foul Time
Request Line 4 Request Foul
Reaest lines 2.3 Time
gear'
Cancel/Fufilf
M
_FeDs' My Foul Time>,
TrackOueoue Other FoulTime
Request Foul Time
I
Other Foul Time
*
4
Foul
Track C.
Time Request
- 2
Betweon/at: w 73.6 Mill River Jct
S81.4 Branford Statiui
Start time:
i2 "0prnj
- History
Track Out of Service Report
(Foul Time)
History
c4
Track Out of Service Report
(Form B)
Find track out of service between:
- 72.3 Noew Haven
end
- 22.7 Boston
Find track out of service between:
- 72.3 New Haven
end
- 228.7 Boston
t
t
l
st update: Fri,
4 w History
4 - History
Track out of service
(Foul Time)
Sun, 10.59p
2.Slp Main Mene
North East Corridor
dispatcher has received your
request and will respond as soon as
T#
Between
Owner
possible..
Please wait
reviews
Mein Menu
ganmene
Scmd requtes
f
Send requeun)
ein Menu
Send requetn
End Time
Track Outage
q
1 Attleboro and Holden Oriol
while dispatcher
and
Route 128 Smith
1 Junction
2 Old Saybrook nd View Green
your request...
Press'Check Response'button to
update this message.
(Check ResponseE )
Mein Menu
M
Track
4 - History
out of service
(Form B)
Sun, 11.00p
T#
Between
Owner
2 Kingston and Davisville Oriol
2 Hyde Park and Forest Hills Green
2
Branford and Pine Smith
Mein
Menu
I
1
3
ARE
4
4 - History
Please confirm Foul Time
- History
NOT UNDER
DISPRTCHER PROTECTION
Check back in35 min
Dispatcher does not accept your
request.
You will have to submit another
request if you want protection.
YOU
Date: 01/28/2088
to: Oriol
to foul 2 track
Mill River Jct and
Branford Station
Issued: 9:05p Alowed: 9:25p
Dispatcher: North East Corridor
Delivered
Permission
between/at
Main Menu
Mccepts
fl-
(onetAccept)
4
History
YOU ROE NOT UNDER
DISPATCHER PROTECTION
Fri, 3.23p
North East Corridor dispatcher has
received your request and the foul
time is now clear
You will have to submit another
request If you want protection.
History
u
foul Time is Effective
Date: 01/28/200
Delivered to: Oriol
Permission to foul 2 track
between/at Mill River Jct and
Branford Station 2
Issued: 9:05p Rilowed: 9: 5p
Dispatcher: North East Corridor
Mein Menu
eaie mece
Table A-4 PID Screen shots (4)
As we can see in Table A-I through Table A-4, the main menu is divided in three submenus.
One of them refers to train location and territory information and the other two refer to work
requests (form D or foul time).
From the train and territory information submenu, there is access to train status information,
territory information and real-time train schedule. Following the link 'Train Status' a roadway
61
worker can retrieve, for a given train, its current delay, last location and time at that location,
next location and expected time at that location, destination, number of cars and engine number.
Following the link 'Territory Information' and for a given section of the track, the roadway
worker can learn about maximum train speed, dispatcher in charge of that territory and rules that
apply. The roadway worker can retrieve real time train schedule, or train OS, from two
perspectives. Following the link 'Train OS (ID)' and for a given train ID, the roadway worker
obtains the train OS since the beginning of its journey. Following the link 'Train OS (work site)'
and for a given section of the track and window of time, the roadway worker can obtain a list of
trains that occupied or were expected to occupy that track during that time.
From the work requests submenus the roadway worker can request form Ds (line 4 or lines 2
and 3) and foul time. Following 'My Form D' or 'My Foul Time' links the roadway worker can
retrieve a list of form Ds or foul time under his/her authority and also continue an interrupted
work request. Following the links 'Cancel/Fulfill' or 'Clear' the roadway worker is able to give
some track under his authority back to the dispatcher. Following the links 'Track Outage' or
'Other Foul Time' the roadway worker is able to find out if, for a given section of the track, there
is some track out of service under form D or foul time.
A.].2.
Web server.
The web server is now running in a computer of the Volpe National Transportation Systems
Center. Its address is rail-datalink.volpe.dot.gov.
A.1.3. Query servers.
Query servers are mainly written in Java. There is only one file written in Perl. This file is a
CGI script used as an interface between the web server and the query servers.
The Perl file is located at: /data/rail-datalink.volpe.dot.gov/cgi-bin/query. pl
It simply reads the HTML forms as sent by the PID, stores a file with the request description
in /data/rail-datalink.volpe.dot.gov/cgi-data/ (where the query servers are looking for them) and
finally reads and returns the requested information to the PID.
There are 5 query servers: Database, dispatcher, file, dispatcher terminal refresh and
simulation query servers. Every second these query servers look for requests sent by the PID or
62
by a dispatcher in the directory /data/rail-datalink.volpe.dot.gov/cgi-data/. In case a request has
arrived to the system, the appropriate query server reads the request, processes it and writes the
answer in /data/rail-datalink.volpe.dot.gov/cgi-data/ for the CGI script to send it back to the original
petitioner. A detailed description of the purpose of each server follows. In parenthesis after each
request it is written the option (op) parameter associated to it. Also, after the name of each query
server it is written the type of query (tq) parameter that identifies the requests that each server
handles (see A.2).
1.
Database query server (tq=db). Handles requests sent by PID that need access to the train
schedule database and the database updates sent from the database manager interface. These
requests are:
Train Status (op=TST): Receives a train ID as input and returns the current status of that
train. The train status includes for all trains: current delay in minutes, last location, next
location, time at these two locations, destination, number of cars and engine number.
Train OS (work site) (op=TSW): Receives a time window and a portion of track as input
and returns the real time train OS of all the trains that occupy that portion of track in the
given time window.
Train OS (ID) (op=TS): Receives a train ID as input and returns its real time train OS
from the beginning to the end of its journey.
Territory Information (op=TI): Receives a portion of track as input and returns the rules
that apply in that territory, the dispatcher in charge and the maximum train speed.
Update database (op=updateSchedule): Manual update of the database (see A. 1.6). The
database manager uses this request to manually update the delay of any train in the
system. This request can also be used to reset the schedule of the trains. At the end of the
day the train schedule is automatically reset to reflect the next day schedule but, should
the database manager want to do it manually this request has the option for him/her.
Update database from file (op=update): Automatic update of the database (see A. 1.4).
This request is supposed to be triggered automatically every given time. It was included
as an interface between a potential real time database and the PID database.
For a detailed description of how database requests are implemented in the PID see A.2
63
2. Dispatcher query server (tq=di). Handles requests sent by PID that need dispatcher
interaction, requests that have to do with work permissions and answers sent by dispatcher to
the PID. These requests are:
Requests sent by PID:
Request form D line 4 (op=FD4): Used to send to the dispatcher a work site description,
track number and desired window of time to perform a work that will require a form D
line 4 authorization.
Request form D lines 2 and 3 (op=FD23): Used whenever a roadway worker wants to
operate a track car. This movement requires form D lines 2 and 3 authorization and this
request is used to send to the dispatcher the portion of track, track number and the
direction of travel.
Ask for time effective or cancel form D (op=FDATE): A form D is not active until the
dispatcher assigns a time effective. Once the dispatcher has assigned a time effective the
form D becomes a rule. But before this step, the roadway worker has to acknowledge that
the dispatcher has understood his/her request so it is the roadway worker the one that has
to confirm the form D by asking a time effective to the dispatcher.
This request receives just the acceptation or rejection of the form D as input. If the
roadway worker accepts the form D, the dispatcher will assign a time effective and it will
become rule until it is cancelled or fulfilled. If the roadway worker rejects the form D, the
entire form D request procedure will have to be repeated.
Retrieve list of active form Ds (op=FDCR): Used whenever a roadway worker has
finished his/her job or wants to cancel or fulfill a form D and is giving the track back to
the dispatcher. This request will send him/her a list of his/her active form Ds and will let
him/her select the one he/she wants.
Cancel/fulfill form D (op=FDC): Works together with the previous request. This is the
step to actually cancel or fulfill the form D.
My form Ds (op=MyFD): Used to retrieve a list of current form Ds or incomplete form
D requests under the authority of the roadway worker holding the PID. Although it is not
included in the first prototype of the PID, this request should also comply with rule 176.
64
"Form D's which have been fulfilled or cancelled [...] must be retained and held
available for inspection for a period of 7 days" (NORAC operating rules)
Track outage (op=FDR): Used to retrieve a list of track currently out of service under
form D authorization. Receives a portion of track as input and, for every section of track
out of service within those given limits, it returns a list of track numbers and track
owners. This knowledge will let the PID holder know who should he/she contact in case
he/she wants access to that portion of track.
Request foul time (op=FT): Used to send to the dispatcher a work site description, track
number and desired window of time to perform a work that will require foul time
authorization.
Accept or do not accept foul time (op=FTAC): It is a roadway worker acknowledgement.
This request receives just the acceptation or rejection of the foul time as input. If the
roadway worker accepts the foul time, it will become active. If the roadway worker
rejects the foul time, the entire foul time request procedure will have to be repeated.
Retrieve list of active foul time (op=FTCR): Used whenever a roadway worker has
finished his/her job or wants to clear a foul time and is giving the track back to the
dispatcher. This request will send him/her a list of his active foul times and will let
him/her select the one he/she wants.
Clear foul time (op=FTC): Works together with the previous request. This is the step to
actually clear the foul time.
My foul time (op=MyFT): Used to retrieve a list of current foul times or incomplete foul
time requests under the authority of the roadway worker holding the PID.
Other foul time (op=FTR): Used to retrieve a list of track currently out of service under
foul time authorization. Receives a portion of track as input and, for every section of
track out of service within those given limits, it returns a list of track numbers and track
owners. This knowledge will let the PID holder know who should he/she contact in case
he/she wants access to that portion of track.
65
Requests sent by dispatchers:
New dispatcher (login) (op=ND): Used whenever a new dispatcher enters the system.
This request receives a territory description and a password as input and it returns a full
dispatcher terminal that will receive any request that has to do with the given territory.
Dispatchers have to login the system before they are able to receive requests from the
PID.
Answer request for form D lines 2 and 3 (op=FD23A): Used by a dispatcher to grant or
deny the requested form D lines 2 and 3. In case the dispatcher grants the form D, he/she
will send to the roadway worker that made the request the appropriate information about
it. This information includes form D number (automatically assigned by system), form D
recipient, date, direction of travel, track number, track location and information about
trains or track cars ahead. In case the dispatcher denies the requested form D it will be
cancelled and the roadway worker will be notified.
Answer request for form D line4 (op=FD4A): Used by a dispatcher to grant or deny the
requested form D lines 4. In case the dispatcher grants the form D, he/she will send to the
roadway worker that made the request the appropriate information about it. This
information includes form D number (automatically assigned by system), form D
recipient, date, track number, track location and foreman in charge of the track out of
service. In case the dispatcher denies the requested form D it will be cancelled and the
roadway worker will be notified.
Assign time effective for form D (op=FDGTE): Once the roadway worker has received
and acknowledged the previous information for any form D, the dispatcher assigns a time
effective to it. The time effective is sent to the roadway worker and the dispatcher is
notified of its reception.
Answer request for foul time (op=FTA): Used by a dispatcher to grant or deny the
requested foul time. In case the dispatcher grants the foul, he/she will send to the
roadway worker that made the request the appropriate information about it. This
information includes track number, time issued, time allowed, employee in charge and
track location. In case the dispatcher denies the requested foul time it will be cleared and
the roadway worker will be notified.
66
For a detailed description of how dispatcher requests are implemented in the PID see A.2
3. File query server (tq=file). Handles requests sent by PID or by the dispatcher that only
require reading a file or finding out if a file exists or not. These requests are:
Items in My form Ds or My foul Time reports (op=SF or LF): Form Ds and foul times
are not stored in the PID. They are stored in the machine running the web server. When a
roadway worker wants to know about his/her own form Ds or foul time, he/she uses the
PID to retrieve it from the web server. The roadway worker won't look for the specific
file name. He/she will only tell the PID that he/she wants to retrieve a specific form D
number or a given foul time.
Wait screens (op=LF): While the roadway worker or a dispatcher are waiting for the
other end to answer a request, a "please wait" screen lets the user know about it. Since
the Palm VII has no way to receive information until it asks for it, this "please wait"
screen has a button that the roadway worker will use to check whether the answer is
available or not. If the answer is available, it will be sent, if it is not available an updated
"please wait" screen will be sent.
On the other hand, the dispatcher terminal (running in a standard web browser) has the
ability to periodically check for answers from the PID.
4. Dispatcher Terminal Refresh query server.
The dispatcher terminal must reflect in real time the current state of the work requests.
This server is responsible to keep updated every 10 seconds this information.
5.
Simulation query server.
Used to conduct the experiment. This server is responsible to send the proposed tasks to
the test users whenever he/she is ready to do so.
Refer to javadoc output (comments in source code that are formatted as web pages) for more
details (/export/home/oriol/java/doc/)
67
A.1.4. Database.
The database includes information about dispatchers, roadway workers, track (type of
territory, dispatcher in charge, maximum train speed) and trains (ID, schedule, engine number,
number of cars, direction of travel and days run). For the purpose of the experiments, the
database also includes information about tasks to be done by test users and initial delays for train
during the experiment.
Six types of text files are used to load the database. Following is a description of their
functionality and their format. They are all located at: /export/home/oriol/database/
The data files are tab separated text files. In the description of each file, we will use the
convention: <field><field> to indicate different fields separated by tabulation. Also, whenever
there is a field described as <text>, it means that any text must be written. This text will be read
but ignored and it is only present for explicitness of the data file while it is created.
1.
Dispatchers (dispatchers.txt). Includes name of the dispatcher, branch (not used), limits of the
territory under his/her authority (initial mile post and final milepost), a territory ID and the
password needed during login.
The format of this data file is as follows:
<header line >
<dispatcher I name><Branch><lnitial milepost><Final milepost><territory ID><password>
<dispatcher 2 name><Branch><Initial milepost><Final milepost><territory ID><password>
<dispatcher n name><Branch><Initial milepost><Final milepost><territory ID><password>
The header line is ignored and there can be as many other lines as dispatchers are involved.
There is a special type of dispatcher used while developing the system. It is a computersimulated dispatcher that will always grant work permissions. Its ID is '00' (two zeros) and it
is supposed to be in charge of all the available territory.
The territory ID's are used internally by the query servers. They have to be unique.
68
Example of data file:
Name
Branch
Initial MP
Final MP
ID
Password
New Haven
SL
72
73
NH
NH
Shore Line
SL
73
125
SL
SL
Main Line
SL
125
190
ML
ML
Table A-5 Example of dispatcher's data file.
2. Roadway workers (MWForemen.txt). Includes information about registered PIDs and their
owner.
The format of this data file is as follows:
<header line >
<roadway worker 1 name><device ID><roadway worker 1 ID>
<roadway worker 2 name><device ID><roadway worker 2 ID>
<roadway worker n name><device ID><roadway worker n ID>
The header line is ignored and there can be as many other lines as PID devices. There are two
special types of roadway workers used while developing the system. The palm emulator has
device id set to "0.0.0". Also, requests coming from a web browser and not from a PID were
also allowed by creating an entry in this data file with device id set to "%DEVICEID".
The roadway worker ID's are used internally by the query servers. They have to be unique.
Example of data file:
Name
Palm ID
ID
Oriol
%DEVICEID
BB
Emulator
0.0.0
EE
HMSL
1.16313097.185173832
11
Table A-6 Example of roadway worker's data file
3. Track information ("Track Info.txt"). Includes information about all the locations along the
track (milepost, dispatcher in charge, maximum train speed, interlocking or station), the
maximum number of parallel tracks, the rules that apply in each track between every two
locations and whether each location is a control point or not. Control points or scheduled
sites, will be the only locations sent to the PID when a train OS is requested.
69
The format of this data file is as follows:
<text><# tracks=k><text><text><text><text><track 1 #><track 2 #>... < track k #><text><text>
<site ID=1><site 1 name><TD><MP><int? XI-><'ps? XI-><rule track 1>...<rule tk k><MS><sch? Xi->
<site ID=2><site 2 name><TD><MP><int? X-><ps? XI-><rule track 1>... <rule tk k><MS><sch? X|->
<site ID=n><site n name><TD><MP><int? Xf-><ps? XI-><rule track 1>... <rule tk k><MS><sch? X|->
In this data file, the header line contains information about the maximum number of tracks
(field <# tracks=k>) and the numbers assigned to each track (fields <track 1 #> through <track k
#>). Note that there are several <text> fields that will be read but ignored.
There can be as many lines as locations along the track considered. The information
contained in each line is:
<site ID=i>: Site ID in ascending order starting from 1.
<site i name>: Site name.
<TD>: ID of dispatcher in charge of this location.
<MP>: Milepost of this location.
<int? XI->: 'X' if the site is an interlocking and any other character if it is not.
<ps? X->:'X' if the site is a passenger station and any other character if it is not.
<rule track 1>... <rule tk k>: Rule that apply in this track (referred to the numbers assigned in the
header).
<MS>: Maximum speed between this location and the following one.
<sch? XI->: 'X' if this location should be sent to the PID when a train OS is requested.
70
Example of data file:
Site ID
4
TD
MP
In
PS
4
2
1
3
MS
Sch site
1
New Haven
NH
72.3
X
X
261
261
261
261
35
X
2
Fair St
NH
72.7
X
-
261
261
261
261
35
X
3
Mill River Jct
SL
73.6
X
-
261
261
261
261
35
X
Table A-7 Example of track information data file
4.
Schedule file ("Boston-New Haven.txt" and "New Haven-Boston.txt"). Includes information
about scheduled trains (ID, schedule, engine number, number of cars, direction of travel and
days run)
The format of this data file is as follows:
<text><UPIDOWN><train 1 ID><train 2 ID>...<train k ID>
<text><text><train 1 engine #><train 2 engine #>... <train k engine #>
<text><text><train 1 # of cars><train 2 # of cars >... <train k # of cars >
<text><text><train 1 days run><train 2 days run >... <train k days run >
<location ID><text><train 1 schedule info>< train 2 schedule info >... < train k schedule info >
<location ID><text><train 1 schedule info>< train 2 schedule info >... < train k schedule info >
There can be as many lines as locations along the track are considered to be scheduled sites
for this group of trains. This number can be less than or equal to the number of locations
identified as scheduled sites in the track information data file.
The information contained in each line is:
<UPIDOWN>: UP if these trains go through the locations in ascending order, DOWN
otherwise.
<train k ID>: Any string that uniquely identifies this train. The database file is organized in
such a way that this is like a column header. Any information below this ID will belong to
the train whose ID is given here.
<train k engine #>: Any string that identifies the engine number of this train.
<train k # of cars>: Any integer that identifies the number of cars in the consist of this train.
71
<train k days run >: A string that identifies the days of the week when this train runs. The
format allowed is very flexible and can be any string as described in the section "Codes used
in train schedules" from the "Northeast corridor employee timetable" which is a part of
NORAC rules.
<location ID>: Integer that matches a scheduled location ID given in the track information data
file.
< train k schedule info >: A string with the following format: '[cb]HH.mm[b+] I null[b+] I -text'.
If the string is [cb]HH.mm[b+] then its meaning is: 'cb' is an optional prefix where 'c' is a
character and 'b' is a blank space. The meaning of 'c' is explained in the section "Codes used
in train schedules" from the "Northeast corridor employee timetable" which is a part of
NORAC rules. 'HH.mm' is the scheduled time in 24 hour format for this train at the location
given in the beginning of this line. 'b+' is an optional postfix where 'b' is a blank space and
'+'
indicates that the time given by 'HH.mm' belongs to the following day
If the string is null[b+] then it means that the scheduled time for the train at this location will
be found later on by linear interpolation between the two closest locations that have been
given an scheduled time in the database. 'b+' is an optional postfix where 'b' is a blank space
and '+' indicates that when the scheduled time is interpolated, it will belong to the following
day.
If the string is -text then it means that the train does not pass by this location.
Example of database:
Direction DOWN
013
095
827
-
Engine number
1211
1266
1748
-
Number of cars
12
11
5
-
-
Daily
M-F
M-F
60
58
Boston
Cove
-SPG
-SPG
S6.17 S23.59
null
23.59
57
56
54
52
50
49
48
Table
Back Bay
-SPG
null
00.00 +
Ruggles St
-SPG
null
null +
Forest Hills
-SPG
null
null +
Hyde Park
-SPG
null
null +
Readville
-SPG
null
null +
Transfer
-SPG
6.34 null +
Route 128
-SPG
R 6.38 S 00.23 +
A-8 Example of train schedule data file
72
We can see that all these trains go DOWN this is in descending order considering the
location IDs given in the track information file. Train 013 runs daily but does not pass by any
location between Boston and Route 128 because it uses another branch. Train 095 has 11
cars, its engine number in 1266 and runs from Monday through Friday. It has a regular stop
to receive or discharge travelers at Boston (given by the 'S') and although it passes by the
locations between Cove and Readville, we don't have the exact times. The servers find these
times by interpolation between Boston at 6.17am and Transfer at 6.34am. Train 095 has a
stop only to receive passenger (given by the 'R') at Transfer. Train 827 initiates its journey at
Boston at 11.59pm and it is due at Route 128 by 12:23am of the following day. The times in
between will be interpolated and assigned also to the following day.
5. Test user tasks ("testUser1.txt"). Includes the text and simulated time of each task that the test
user received during the experiments in the laboratory.
The format of this data file is as follows:
<time 1><task 1>
<time n><task n>
There can be as many tasks as desired. The information contained in each line is:
<time>: Time that will be considered as actual time when this task is in effect. It has the
format: MM/dd/yyyy HH.mm
<task>: Text description of the task.
Example of data file:
01/20/2000 15.45 You will need to foul track 2 between New London and Groton during
45 minutes. Find out some time to do this job and ask for foul time.
01/20/2000 17.15 You have just finished your job between New London and Groton.
Please clear the foul time.
Table A-9 Example of test user's tasks data file
73
6. Initial delays for the simulated tasks ("Initial Delays.txt"). Includes the initial delays that the
trains in the database had during the experiments.
The format of this data file is as follows:
<header line>
<train ID 1><delay 1>
<train ID n><delay n>
The header line is read but ignored and there can be as many delayed trains as desired. The
information contained in each line is:
<train ID>: ID of the train that is going to have the delay. This ID should match one of the IDs
given in the schedule files.
<delay>: Delay in minutes.
Example of data file:
Train ID
Minutes
084
30
093
22
Table A-10 Example of initial train delays data file
Database templates
To build all these data files we used excel worksheets. Each database is in one worksheet
and can be saved by using the "save as... text (tab delimited)" excel option.
These templates are in: /export/home/oriol/database/databaseTemplates.xs
A.1.5. Dispatcherinterface.
When the system is running, any web browser can be turned into a dispatcher interface. If a
dispatcher wants to enter the system he/she will only have to hit the page http://raildatalink.volpe.dot.gov/dispatcher/login.html and, after selecting a territory and entering the
appropriate password he/she will be logged as the dispatcher in charge of that territory. The
system will generate a message console for him/her and all the incoming messages that affect the
selected territory will be shown to him/her.
74
We can see in Figure A-I the dispatcher interface. This framed web page is configurable by
modifying the following master files (see A.3): masterTerminalMain.html, masterTerminalO.html,
masterTerminall.html, masterTerminal2.html, masterTerminal3.html
The number of files is given by the configurable variable (see A.5) NUMTERMINALPAGES
from file fileLocation.java. Its current value is 4.
Requested
Requested Form Ds
* 0003, Oriol - Read
* 0002, Oriol - Read
Active
Rejected and canceled
Form D 0003 is Requested
Requested Foul Time
. 10.00a-10.30a, Oriol -
Read
Foreman Oriol would like to work in 1 track at/between Branford and
Guilford
Desired starting time:
11.00a
Expected duration of work: 1 hour
Form D #:
0003
Delivered to: Oriol
Date:
01/28/2000
Line 4:
1
track out of service between/at
181.5 Bronford
and 190.4 Guilford
charge oflOr.OlI
'A in
Train
North East Corridor
Dispatcher:
Form Ds waiting for time
effective
* 0004, Oriol - Read
Please select 'Confirm' to grant permission to work or 'Deny' to disregard this
form D request and then press 'Send Response'
(k Confirm
r Deny
Reason _____________.
Figure A-1 Dispatcher interface
A.]. 6. Databasemanager interface.
When the system is running, any web browser can be turned into a database manager
interface by hitting the page http://rail-datalink.volpe.dot.gov/dispatcher/CTC.html. From this
page a database manager can manually update delays of the trains in the system
We can see in Figure A-2 the database manager interface. This web page is configurable by
modifying the master file (see A.3) masterCTC.html.
75
Train schedule update
Train Current
iD
delay
Lastlocation Time atlast New
Reset
delay schedule
location
012
0
Branford Station
9.17a
[
013
0
New Haven
5.02a
Flf
r
055
0
MillRiver Jct
3.47p
[
r
056
0
New Haven
1.07p
[7
r
066
3
Boston
6.58a
067
0
Boston
8.00p
076
3
Boston
6.58a
084
5
New Haven
2.09p
093
0
Providence
9.16a
F
094
5
New Haven
6.29p
F
095
0
New Haven
9.00a
099.
-0............ProvIdenrm ............ 9-1.6a
932
0
Boston
1226a
977
0
Boston
3.55p
978
0
Canton Junction
4.39p
WX105
0
New London
1.19p
WX305
0
Atwells
10.19a
7l
F
[7
[L7
F2
F-
F
....
...............
r.......7.........
[
Fl
flf
[
F
F
Figure A-2 Database manager interface
A.2.
Type of requests
Each one of the requests described in A.1.3 has a number of parameters with different
meanings. For future reference, the following is a list of these parameters.
76
1. Database query server requests.
Database requests (tq=db)
Train Status
tq
op
d
p1
p2
p3
p4
db
TST
%deviceid
hundreds
tens
units
Train Status - List Train OS (work site)
db
db
TST
%deviceid
train id
TSW
%deviceid
site 1
site 2
Initial time
Time span
tq
op
d
p1
p2
p3
Remarks
Train OS (ID) - List
Get List of trains
db
db
db
TS
%deviceid
hundreds
tens
units
TS
%deviceid
train id
LT
%deviceid
range
TST I TS
Train Id is formed by
rain Id is formed by
appending the digits
Remarks
given by p1,p2 and
p3
Territory Info
db
TI
%deviceid
site 1
site 2
Train OS (ID)
appending the digits
given by p1,p2 and p3
Update database
db
updateSchedule
ctc
xxx-yyy-zzz-... (train ID's)
mmx-mmy-mmz-... (delays)
aaa-bbb-ccc-... (train ID's)
Update database from file
db
update
ctc
p1, p2 and p3 are undescore separated lists
of data. p1 and p2 form pairs (trand ID,
The file used to automatically update the
schedule is: /export/home/oriol/database/
delay) while p3 is a list of train ID whose
updateSchedule.txt
schedule must be reset.
%deviceid is a palm VII specific parameter. It will show what palm VII device is sending the request.
Table A-11 Database query server parameters.
p2 indicates whether
the list is created to
retrieve a train status
or a train OS
2. Dispatcher query server requests.
Dispatcher requests (tq=di)
Request Form D L4
tq
op
d
p1
p2
p3
p4
p5
di
FD4
%deviceid
site 1
site 2
track number
Start time
Duration
Request FormD L2
and L3
di
FD23
%deviceid
site 1
site 2
track number
Direction
Remarks
Request Foul Time
tq
op
d
p1
p2
p3
p4
p5
Remarks
di
FT
%deviceid
site 1
site 2
Track Number
Start time
End time
Accept or do not
accept foul time
di
FTAC
%deviceid
Foul time index #
Dispatcher ID
1 I0
Ask for time
effective or cancel
Form D L4
Ask for time
effective or cancel
Form D L2 and L3
di
FDATE
%deviceid
form D #
Dispatcher ID
1 | 0
di
FDATE
%deviceid
form D #
Dispatcher ID
1 10
p3=1: Ask for Time
effective;
p3=0
p3=1: Ask for Time
effective;
cancel form D
p3=0 cancel form D
Track outage
Other foul time
di
FDR
%deviceid
site 1
site 2
di
FTR
%deviceid
site 1
site 2
Cancel or fulfill
form D
Clear foul time
di
FDC
%deviceid
nnnnDD
di
FTC
%deviceid
nnnnDD
nnnn: 4 digit foul time nnnn: 4 digit foul time
index;
DD: index;
DD:
dispatcher
New dispatcher
(login)
di
ND
login
Dispatcher ID
Password
p3=1: Accept
p3=0: Do not accept
%deviceid is a palm VII specific parameter. It will show what palm VII device is sending the request.
Table A-12 Dispatcher query server parameters (1)
ID
dispatcher
ID
Dispatcher query server requests (cont)
Dispatcher requests (tq=di)
Answer request for
form D L4
tq
op
d
p1
p2
p3
p4
p5
p6
p7
p8
p9
p10
di
FD4A
dispatcherDD
Form D #
Dispatcher ID
Track #
Site 1
Site 2
In charge of
1 10
Reason
Assign time
Assign time
Answer request for
effective for form D effective for form D
foul time
L2 and L3
L4
di
di
di
di
FTA
FDGTE
FDGTE
FD23A
dispatcherDD
dispatcherDD
dispatcherDD
dispatcherDD
Foul Time Index #
Form D #
Form D #
Form D #
Dispatcher ID
Dispatcher ID
Dispatcher ID
Dispatcher ID
Track #
Time effective
Time effective
Direction
Site 1
Track #
Site 2
Site 1
Time Issued
Site 2
Time Allowed
Trains / tk cars ahead
1 0
Stop Signal
Reason
1 1 0
Reason
Answer request for
form D L2 and L3
d: dispatcher+D p7=1: d: dispatcher+ID p9=1:
Remarks Grant
p7=0: Deny Grant
p9=0: Deny
p8: Reason if denied p1 0: Reason if denied
tq
op
d
My form Ds
My foul time
di
MyFD
%deviceid
di
MyFT
%deviceid
d: dispatcher+ID p7=1: d: dispatcher+ID p9=1:
p9=0: Deny
p7=0: Deny Grant
Remarks Grant
p8: Reason if denied p1 0: Reason if denied
d: dispatcher+ID
d: dispatcher+ID
d: dispatcher+ID
Retrieve list of
active Form Ds
di
FDCR
%deviceid
Retrieve list of
active Foul Time
di
FTCR
%deviceid
d: dispatcher+ID
d: dispatcher+ID
p8=0: Deny
p9:
Reason if denied
%deviceid is a palm VII specific parameter. It will show what palm VII device is sending the request.
Table A-13 Dispatcher requests parameters (2)
3. File query server.
File requests (tq=file)
tq
op
d
p1
p2
p3
p4
p5
p6
Remarks
Please wait screen (dispatcher)
file
LF
terminalXXXXYYY
Data file name
Word 1
Word 2
Refresh Interval
Done file Name
Type of Wait Screen
Please wait screen (PID)
file
LF
%devicelD
Data file name
Word 1
Word 2
Refresh Interval
Done file Name
Type of Wait Screen
Send File
file
SF
%devicelD
File name
If Done file name exists then Data file name
is sent. Else, a new "please wait" screen of
type defined by p6 is returned (see A.5.)
If Done file name exists then Data file name
is sent. Else, a new "please wait" screen of
type defined by p6 is returned (see A.5.)
The file given by p1 will be sent to
the PID
%deviceid is a palm VII specific parameter. It will show what palm VIl device is sending the request.
Table A-14 File query server parameters
5. Simulation query server.
4. Dispatcher Terminal Refresh query server
tq
op
d
p1
File requests (tq=refreshTerminal)
Simulation requests (tq=sim)
Refresh Frame
refreshTerminal
RT
Frame ID
File name
Next Task
sim
newTask
userNN
Next Task
Refresh the frame given by frame ID with the
Remarks
HTML file name given by p1.
tq
op
d
p1
p2
Frame
ID = dispatcher ID + frame type (active form
D, requested foul time,... )+.html (see A.3.)
Table A-15 Terminal refresh query server parameters
Remarks
Test User #
Sends the task given by p1 to the test user
number given by p2
Table A-16 Simulation query server parameters
A.3.
Master files
The system is designed to be highly configurable. To achieve this goal, all the information
that is displayed to the dispatcher or sent to the PID is not included in the source code of the
servers. It is stored in what is called the master files. The master files are just templates of
HTML files that are read by the servers and filled with the correct information every time they
are used.
To understand this concept, let's use a simple master file: masterTrainStatus.html
Train {-0-}
{-5-}
Status:
Last:
Next:
Destination:
Engine #:
# of cars:
Main Menu
{-1-}
{-2-} {-4-}
{-6-} {-7-}
{-3-}
{-1-}
{-11-}
Figure A-3 Rendering of masterTrainStatus.html
Figure A-3 is the rendering of the HTML code that is included in the masterTrainStatus.html
file, but it is not, of course, what is shown in the PID when a train status is requested. When a
train status request arrives, the database query server reads the request description (trainID) then
it searches the database for information about the train and finally, it reads the template
masterTrainStatus.html with the following parameters:
Train ID: {-O-}
Next Interlocking: {-6-}
Train Status: {-1-}
Time at next Interlocking: {-7-}
Last Interlocking: {-2-}
Milepost at last interlocking: {-8-}
Now heading to station: {-3-}
Milepost at next interlocking: {-9-}
Time by last interlocking: {-4-}
Engine number: {-IO-}
Actual time: {-5-}
Number of cars: {- I-}
82
Then it substitutes the fields {-n-} by the correct value and sends the information to the PID.
This adds a lot of flexibility to the system because the master file can be modified, and thus the
user-interface, without having to change the source code. The parameters passed to the template
are fixed and can't be changed without modifying the source code.
With the idea of the master files, the user interface has been separated to the maximum
extent from the source code of the servers. The master files (written in HTML) can be modified
as long as the numbering of the parameters is preserved.
There are more complex examples of master files such as the schedule table sent to PID. The
information seen at the PID is the result of appending several master files into only one final file.
There are also master files that are read more than once every time they are accessed. This is the
case of items in lists such as the ones showed in the dispatcher interface. We refer to the
comments in the source code of the master files to understand the details of each one of them.
We will now group, locate and enumerate the various master files and we will make a short
description of them. All these files have HTML comments that can be reviewed for further
information.
1.
Files sent to the PID
PATH: /export/home/oriol/MasterFiles/clipping/
All these are files that will be sent to the PID. On the right column we note the conditions
under which the file on the left is sent to the PID.
MasterDispatcherNotOnline.html
Dispatcher is not online and can't receive requests
MasterEmptyFDReport. html
There is no track out of service (under form D authority) in the
requested section of track.
MasterEmptyFTReport. html
There is no track out of service (under foul time authority) in
the requested section of track.
MasterFDCancelEmptyReport. html
The PID owner does not have form Ds to cancel
MasterFDCancelEmptyRequest. html
The PID owner has not cancelled any form D.
Table A-17 Master clipping files (1)
83
MasterFDCancelled.html
Lets the PID owner know that he/she is no longer under form D
protection.
MasterFDCancelReport. html
The PID owner requests a list of his/her active form Ds and
he/she wants to cancel or fulfill one of them.
MasterFDL23Active.html
Form D (lines 2 and 3) is effective.
MasterFDL23NotActive.html
Form D (lines 2 and 3) must be acknowledged by the PID
owner. He/she will ask for time effective or cancel the form D
MasterFDL4Active.html
Form D (line 4) is effective.
MasterFDL4NotActive.html
The PID owner must acknowledge form D (line 4). He/she will
ask for time effective or cancel the form D
masterFDRejected.html
Let the PID owner know that the dispatcher does not accept
the form D he/she had requested.
masterFDReport.html
Report of track out of service under form D.
masterFTActive.html
Foul time is effective.
masterFTCancelEmptyReport.html
The PID owner does not have foul time to clear.
masterFTCancelEmptyRequest.html
The PID owner has not cancelled any foul time.
masterFTCancelled.html
Let the PID owner know that he/she is no longer under foul
time protection.
masterFTCancelReport.html
The PID owner requests a list of his/her active foul time and
he/she wants to clear one of them.
masterFTNotActive.html
The PID owner must acknowledge foul time. He/she will accept
or do not accept it.
masterFTRejected.html
Let the PID owner know that the dispatcher does not accept
the foul time he/she had requested.
masterFTReport.html
Report of track out of service under foul time.
masterMyFDReport. html
Report of form D under the authority of the PID owner.
masterMyFTReport. html
Report of foul time under the authority of the PID owner.
masterTrainDoesNotExist.html
The PID asks for information about a train that does not exist.
masterTrainStatus.html
The PID asks for a train status.
masterTS_EmptyListOfTrains.html
There are no train IDs in the requested ID range. It has a link to
train schedule screen
Table A-18 Master clipping files (2)
84
masterTSListOfTrains.html
List of train IDs in the requested range. It has a link to train
schedule screen.
masterTSTEmptyListOfTrains.html
There are no train IDs in the requested ID range. It has a link
to train status screen
masterTSTListOfTrains.html
List of train IDs in the requested range. It has a link to train
status screen.
MasterWaitWhileReview. html
"Please wait" message sent to the PID while the dispatcher
reviews a form D or foul time request.
MasterWaitWhileTimeEffective. html
"Please wait" message sent to the PID while the dispatcher
assigns time effective to a form D.
Table A-19 Master clipping files (3)
PATH: /export/home/oriol/MasterFiles/clipping/lists_anditems/
These are files that are either appended among them or to the ones above to form a complete
information page that will be sent to the PID. On the right column we note the conditions under
which the file on the left is sent to the PID.
emptyltem.html
Empty file
FDActiveltem.html
Active form D displayed in the "my Form D" report.
FDCancelReportltem.html
Active form D that can be cancelled by the PID owner.
FDNotActiveltem.html
Incomplete (not yet acknowledged by roadway worker) form D
displayed in the "my Form D" report.
FDReportItem.html
Section of track out of service under form D protection.
FDRequestltem.html
Incomplete (not yet reviewed by dispatcher) form D displayed
in the "my Form D" report.
FDTimeEffectiveltem.html
Incomplete (without time effective) form D displayed in the "my
Form D" report.
FTActiveltem.html
Active foul time displayed in the "my Foul Time" report.
FTCancelReportltem.html
Active foul time that can be cleared by the PID owner.
FTNotActiveltem.html
Incomplete (not yet acknowledged by roadway worker) foul
time displayed in the "my Foul Time" report.
FTReportItem.html
Section of track out of service under foul time protection.
Table A-20 Master clipping files (4)
85
Incomplete (not yet reviewed by dispatcher) foul time
FTRequestltem.html
displayed in the "my Foul Time" report.
masterScheduleEmpty.html
No trains expected at the time and location requested.
masterScheduleFooter. html
Bottom part of a train schedule report.
masterScheduleHeader. html
Top part of a train schedule report.
masterScheduleTablel Header.html
Header of each section of the train schedule table when this
table has only one column.
masterScheduleTablel ltem.html
Each row of the train schedule table when this table has only
one column.
masterScheduleTable2Header.html
Header of each section of the train schedule table when this
table has two columns.
masterScheduleTable2ltem.html
Each row of the train schedule table when this table has two
columns.
masterScheduleTable3Header.html
Header of each section of the train schedule table when this
table has three columns.
masterScheduleTable3Item.html
Each row of the train schedule table when this table has three
columns.
masterScheduleTable4Header.html
Header of each section of the train schedule table when this
table has four columns.
masterScheduleTable4Item.html
Each row of the train schedule table when this table has four
columns.
masterScheduleTableFooter.html
Footer of each section of the train schedule table
masterTerritoryFooter. html
Bottom part of the territory information report.
masterTerritoryHeader.html
Top part of the territory information report.
masterTerritoryTableFooter. html
Footer of the territory information table.
masterTerritoryTableHeader.html
Header of the territory information table.
masterTerritoryTableltem.html
Each row of the territory information table.
trainListltem.html
Each item of a list of train IDs. Sent whenever the PID user
wants to know about train Ids within a given range of numbers
Table A-21 Master clipping files (5)
86
2. Files sent to the dispatcher or the database manager.
CURRENT PATH: /export/home/oriol/MasterFiles/html/
All these are files that will be sent to the dispatcher or the database manager. On the right
column we note the conditions under which the file on the left is sent to the dispatcher.
masterCTC.html
Database manager interface main file.
MasterEmpty.html
Empty file used when there is nothing to display in the
dispatcher's terminal.
masterFDL23Display. html
General description of a form D lines 2 and 3.
MasterFDL23Request. html
Request of a form D lines 2 and 3.
masterFDL23TimeEffective.html
Assign time effective to a form D lines 2 and 3.
masterFDL4Display.html
General description of a form D line 4.
MasterFDL4Request.html
Request of a form D line 4.
masterFDL4TimeEffective.html
Assign time effective to a form D line 4.
masterFrameRefresh.html
Main file for each frame in the dispatcher interface. It
automatically refreshes the frames with new information.
masterFTDisplay.html
General description of a foul time.
masterFTRequest.html
Request of a foul time.
MasterLogin.html
Login screen.
MasterMsgAfterLogin.html
"Please wait" message while the dispatcher terminal is being
initialized after login.
masterTerminalO.html
Secondary frame description of the dispatcher terminal. *
masterTerminall.html
Secondary frame description of the dispatcher terminal. *
masterTerminal2.html
Secondary frame description of the dispatcher terminal. *
masterTerminal3.html
Secondary frame description of the dispatcher terminal. *
MasterTerminalMain.html
Main frame description of the terminal.
MasterWaitWhileReview.html
"Please wait" message sent to the dispatcher while the
roadway work reviews a form D or foul time request.
*The number of secondary frame descriptions is given in the configuration file. See A.5
Table A-22 Master HTML files (1)
87
CURRENT PATH: /export/home/oriol/MasterFiles/html/lists and items/
These are files that are either appended among them or to the ones above to form a complete
information page that will be sent to the dispatcher. On the right column we note the conditions
under which the file on the left is sent to the dispatcher.
ctcltem.html
Each row of the database manager interface.
FDActiveltem.html
Each row of the active form D list.
FDActiveList.html
Body of the active form D list.
FDCancelledItem.html
Each row of the cancelled form D list.
FDCancelledList.html
Body of the cancelled form D list.
FDRejectedItem.html
Each row of the rejected form D list.
FDRejectedList.html
Body of the rejected form D list.
FDRequestltem.html
Each row of the requested form D list.
FDRequestList.html
Body of the requested form D list.
FDTimeEffectiveltem.html
Each row of the form D without time effective list.
FDTimeEffectiveList.html
Body of the form D without time effective list.
FTActiveltem.html
Each row of the active foul time list.
FTActiveList.html
Body of the active foul time list.
FTCancelledltem.html
Each row of the cleared foul time list.
FTCancelledList.html
Body of the cleared foul time list.
FTRejectedItem.html
Each row of the rejected foul time list.
FTRejectedList.html
Body of the rejected foul time list.
FTRequestltem.html
Each row of the requested foul time list.
FTRequestList.html
Body of the requested foul time list.
Loginltem.html
Each row of the options given in the login window.
Table A-23 Master HTML files (2)
CURRENT PATH: /export/home/oriol/MasterFiles/html/simulation/
MasterSimulation.html
Sent to a test user whenever he/she wants to receive a
new task
Table A-24 Master simulation file
88
3. Files stored in the Palm VII.
CURRENT PATH: /export/home/oriol/MasterFiles/pqa/
These are the HTML files that are stored in the PID. They are static files that are used to
send requests from the PID. On the right column we write a brief description of the request
(HTML form) inside the file on the left
autoReply.html
Test file. Used to tell the server to automatically reply requests from the PID.
This is not part of the final version of the prototype.
FDL23Request.html
Request form D lines 2 and 3.
FDL4Request.html
Request form D line4.
FDReport.html
Find out track out of service under form D authority in a given area.
FTReport.html
Find out track out of service under foul time authority in a given area.
FTRequest.html
Request foul time.
index.html
Index file with links to all the others. It also has embedded requests to:
- Retrieve a list of active form Ds or foul time under the authority of the
PID owner to let him/her fulfill the form D or clear the foul time
-
Retrieve a list of current form D or foul time under the authority of the
PID owner to let him/her review his/her permissions or to continues
incomplete requests.
territory Info. html
Territory information request
TSch.html
Train schedule requests by train ID using numeric keyboards.
TSchWorkingSite.html
Train schedule request by location.
TSList.html
Find out a list of trains within a given train ID range to check their schedule.
TStatus.html
Train status requests by train ID using numeric keyboard.
TSTList.html
Find out a list of trains within a given train ID range to check their status.
Table A-25 Files stored in the Palm VII (PQA)
89
A.4.
Functionality
In this section we will use an example to describe how the components of the system are
linked together. We will follow a simple database request and, at the end, we will make some
comments about how requests that have to be answered by dispatchers are managed.
A. 4.1. Databaserequests
We will follow the train schedule request by working site. The underlying idea of this
request is to let roadway workers know about trains that are expected at their working site while
they are carrying out their duties.
The main menu of the PID prototype is shown in Figure A-4. This is one of the HTML
pages (index.html) that are stored in the Palm VII. If we follow the link Train OS (work site) we
arrive to the "Train OS Request" screen shown in Figure A-5 which is another HTML file
(TSchWorkingSite. html) stored in the Palm VII.
4
C"4TCI
Train 05 Request
Train and territory
information
Train status Territory Info
Train 05 (work site) Train OS (ID)
Form D
Request Line 4
Request Lines 2,3
Cancel/Fulfilli
My Form Ds(
Track Outage
Foul Time
Request Foul
Time
(
My Foul Time
v
From:
1022
To:
w 3hours later.
v
81.5 Branford
93.1 Madison
(Getesschedule
de
Other Foul Time
Figure A-4 index.html
Find train
twee/at:
arn
Moir MeM
Figure A-5 TschWorkingSite.html
TSchWorkingSite.html is just an HTML form. In this screen, the roadway worker would find
the section of the track in which he/she is working. He/she will also be able to introduce the time
window of interest.
Once the roadway worker taps on the "Get Schedule" button (submit button of the HTML
form), a wireless transmission is initiated, as it is indicated by the over the air icon (OTA)
(Figure A-6) located in the button label. Whenever the roadway worker follows a link or taps a
button that has the OTA a wireless transmission will be initiated. This link or button with the
OTA icon will not refer to a local HTML page but to data on the Internet.
90
Figure A-6 Over the air icon
As it can be seen in A.2 the parameters sent are:
tq=db
op=TSW
d=%deviceid
pl=site 1
p2=site 2
p3=Initial time
p4=Time span
tq, op and d are hidden parameters included in every request.
-
tq is the type of query. This parameter will let the system know what server is going to
handle the request.
-
op is the specific option or function that the roadway worker wants to use.
-
d is the ID of the person sending the request. In this case it is %deviceID, which is a
Palm VII specific reserved word that is changed to a numeric code that uniquely
identifies the palm VII device sending the request. The server uses the %deviceID to
identify what roadway worker is sending the request and to keep a log of it. The
%devicelD is also used for authentication. Only registered devices will retrieve
information from the system.
After these parameters comes a list of request specific parameters. In this case pI, p2, p3 and
p4 store the information introduced by the roadway worker when he/she filled the form.
To understand how the HTML form information arrives to the web server refer to Palm VII
white paper and documentation.
The program that receives the form is http://rail-datalink.volpe.dot.gov/cgi-bin/quer.pl
query.pI reads the HTML form and stores its description in /data/rail-datalink.volpe.dot.gov/cgi-data/
in a simple text file that will look like:
91
-tq=db
-op=TSW
-d= x.y.z
-pl=nn
-p2=nn
-p3=hh:mm
-p4=h
The file name will be /data/rail-datalink.volpe.dot.gov/cgi-data/x.y.z.dbq. Whenever this file is
finished, the query.pl program will also write an empty "done" file to let the server know that a
new request has arrived. This "done" file would be called: /data/rail-datalink.volpe.dot.gov/cgidata/x.y.z.dbqdone . After this "done" file is written, query.pi is put to sleep until the answer
arrives for a maximum of 30 seconds.
The query servers are looking in the cgi-data directory for files with the appropriate
extensions. In the case of the database query server, it is looking for files with the dbqdone
extension. Once such a file arrives the query server reads the appropriate .dbq file and processes
it. When the query server is done, it will write the file /data/rail-datalink.volpe.dot.gov/cgidata/x.y.z.dbqdat with the HTML file that contains the requested information. It also writes a new
"done" file /data/rail-datalink.volpe.dot.gov/cgi-data/x.y.z.dbqdatdone used to wake query.pl up. When
this new "done" file is written, query.p reads x.y.z.dbqdat and sends it as an HTML content type
back to the Palm VII. This finishes the process.
All interactions with the servers pass through query.pI and are handled in a similar way. The
parameters d, op and tq are always present although their content may vary. The parameters pl,
p2, ... contain specific information about each request.
A. 4.2. Dispatcherrequests
When a request needs an answer from the dispatcher it will have tq=di and the dispatcher
query server will handle it. query.pI can't be waiting until the dispatcher reviews and answers the
request, nor can the Palm VII stay in waiting mode for such a long and uncertain time. The way
this issue has been addressed is using "please wait" messages.
As soon as the PID sends a request to a dispatcher (i.e. a form D line 4 request), it will
receive a message letting the user know that his/her request has arrived to the appropriate
dispatcher and that he/she must wait until the dispatcher reviews the request. This message has a
92
refresh button that the PID user will have to tap whenever he/she considers that the dispatcher
has already reviewed his/her request. If the dispatcher has indeed answered, this response is sent
to the PID, but if the dispatcher is still reviewing the request, the PID will receive another
"please wait" message.
As a final comment about dispatcher requests, the PID owner does not have to know what
dispatcher is going to answer his/her request. It is the role of the dispatcher query server to route
the request to the appropriate dispatcher depending on the content of the request.
A.5.
Configuration file
As it has been said, we have tried to develop the system as configurable as possible. With
this idea, all configurable parameters have been included in a single file. It is a Java interface
called fileLocation.java
This Java interface contains information about:
-
Directories. Master files local path, output files local path, output files web server path,
database local path.
-
Database file names. Schedules, track description, registered PID owners.
-
Master files. Names for all the master files described in A.3
-
String roots to create file names.
-
Extension recognized by each query server.
-
Miscellaneous parameters (refresh rate for dispatcher terminal frames, database
validation time, number of columns in the table of a territory report, number of columns
in the table of a schedule report, number of secondary frame descriptions for each
dispatcher terminal, html tag used when a forecast is made and various time and date
formats used)
All these parameters may be changed but, since fileLocation.java is part of the source code,
after any modification to this file, the entire program has to be recompiled. To do this, go to
directory /export/home/oriol/java/MWTerminal/ and type javac *.java
93
Appendix B.
Questionnaires
Following the ideas in (Nielsen, J. 1994) and (Kirwan, B, 1992) we have prepared three sets
of questionnaires. These questionnaires were handed to the test users during the experiments.
The first set is just a list of questions about background and demographics of the test user.
The second set was used during the usability test. It was used to evaluate the last iterations
of the PID design for specific major problems and for user's ability to complete the tasks
effectively. This questionnaire helped to identify points of confusion and difficulty.
The third set was used during the system evaluation test. It was used to validate the final
PID design, to check if it met minimum performance levels and to understand its usefulness.
94
Demographic
1. Job title
2. Years of experience
3. Please provide examples of your interaction with
dispatchers and an average number of these
interactions per week [form D (lines?), foul time, signal
shutdown, train schedule update, bridge lock/unlock,
message relay, rule 241, hazard report, TSRB, other...]
Frequency (number of times per week)
Type of interaction
4. Please rate your level of familiarity with the following devices or services
Familiar
Very Familiar
3
4
5
2
3
4
5
1
2
3
4
5
4d. Cellular phone
1
2
3
4
5
4e. World Wide Web
1
2
3
4
5
4f. E-mail
1
2
3
4
5
4g. Palm Pilot
1
2
3
4
5
Very Unfamiliar
Unfamiliar
4a. Radio
1
2
4b. Personal Computer
1
4c. Beeper or Pager
Figure B-1 Demographic questionnaire
95
Miscellaneous
Presentation
1. Please rate how the information is presented to you according to the following attributes.
1a. Font size
1b. Font style (bold, normal, underlined...)
1c. Readability
Very Small
Small
1
2
Very
confusing
Confusing
1
2
Very
Unreadable
Moderately
Unreadable
1
2
3
1
Very big
4
5
Clear
Very Clear
4
5
Moderately
Readable
Very
Readable
4
5
Moderately
Organized
Very
Organized
4
5
Disagree
Agree
Strongly
Agree
2
4
5
2
4
5
2
4
5
2
4
5
4
5
3
3
Very
Moderately
Disorganized Disorganized
1d. Well organized information
Big
2
3
2. Please write down any comments that you might have
about how the information is presented to you. What
would you change if you had the opportunity?
Navigation
3. Please circle your level of agreement with the following statements.
Strongly
Disagree
3a. It is easy to navigate through the menu tree.
1
3b. I was always aware of my location within the menu.
3c. I knew how to navigate to the prior screen.
1
3d. The menu names are meaningful.
3e. The button labels are meaningful.
2
3f. The menu is organized according to railroad
operations needs.
4. What menu names or button label would you change
to clarify the meaning of the commands? Can you
suggest an alternative name?
2
Current menu name or button label
5. If you could change it, would you organize the menu
in a different way? How?
6. Please write down any comments about a particular
problem that you had while navigating.
Figure B-2 Usability test. Questionnaire (1)
96
Alternative
Task realism
7. Please circle your level of agreement with the following statement.
Strongly
Disagree
7a. The tasks proposed in the experiment are close to
typical real interactions with dispatchers.
1
Disagree
2
3
8. Would you include any other type of task in the
experiment? What tasks?
PID Improvement
9. Please write down any other general comments on
how we should improve the PID?
10. Please list and comment on any features that the
PID must have before even considering to use it in
railroad operations.
11. What safety concerns need to be addressed before a
similar device could be used in railroad operations?
12. Do you see any other potential uses for the PID ?
Figure B-3 Usability test. Questionnaire (2)
97
Agree
Strongly
Agree
4
5
Train location and territory information menu
Request screens
1. Please rate the Request Screens on the following attributes
Very
Incomplete
1a. Completeness (whether you could ask for
1
everything you needed or not)
Moderately
Incomplete
2
3
Very
Moderately
Uncooperative Uncooperative
1b. Cooperation (whether the screens are designed to
help you introduce the required information or not)
1c. Complexity (whether the screens are puzzling or
not)
2
Very Complex
Moderately
Complex
1
2
Very Slow
Slow
1d. Speed (whether there was a prompt answer to your
request or not)
1e. Understandability
1f. Entering the information that is needed by the
system
1g. Realism (whether the screens reflect railroad
operation needs or not)
2. Would you include any other information in the
request screens? What information? In what screen?
2
Very Difficult
to Understand
Difficult to
understand
1
2
Very Difficult
Moderately
Difficult
1
2
Very
Unrealistic
Moderately
Unrealistic
1
2
Information
Very
Complete
4
5
Very
Cooperative Cooperative
3
3
3
4
5
Moderately
Simple
Very Simple
4
5
Fast
Very Fast
4
5
Easy to
Very easy to
understand understand
3
3
3
Screen
3. If you could change it, would you present the
requests in a different way? How?
4. What type of sites would you like to have in the drop
down lists (interlockings, stations, platforms, bridges,
other, all of them, some of them,...)?
5. How would you like the site names to be sorted by?
(milepost, name, both, other criteria)
6. Please write down any comments that you might
have about a particular request screen.
Figure B-4 Usability test. Questionnaire (3)
98
Moderately
Complete
4
5
Moderately
Easy
Very Easy
4
5
Moderately
Realistic
Very
Realistic
4
5
Report screens
7. Please rate the Report Screens according to the following attributes
7a. Amount of information.
Very Poor
Poor
1
2
3
Abundant
Very
Abundant
4
5
Expected
Very
Expected
4
5
Easy to use
Very easy to
use
4
5
Very
7b. Expected type of information.
7c. Vertical scroll bar.
Unexpected
Unexpected
1
2
Very difficult
to use
Difficult to use
1
2
3
3
8. What other type of information would you like to
receive? How accurate does this information need to
be?
9. Write down any comments that you might have
about a particular report screen.
10. Is information about train location in the past
relevant to your work? Would you show this
information in the train OS?
11. What other attributes, if any, would you like to
include in the train status?
Figure B-5 Usability test. Questionnaire (4)
99
Form D and Foul Time menus
Request screens
1. Please rate the Request Screens on the following attributes
1 a. Completeness (whether you could ask for everything
you needed or not)
Very
Incomplete
Moderately
Incomplete
1
2
3
Very
Moderately
Uncooperative Uncooperative
1b. Cooperation (whether the screens are designed to
help you introduce the required information or not)
1 c. Complexity (whether the screens are puzzling or not)
1d. Speed (whether there was a prompt answer to your
request or not)
le. Understandability
1
2
Very Complex
Moderately
Complex
1
2
Very Slow
Slow
1
2
Very Difficult
to Understand
Difficult to
understand
1
2
1f. Entering the information that is needed by the system
1g. Realism (whether the screens reflect railroad
operation needs or not)
2. Would you include any other information in the
request screens? What information? In what screen?
Difficult
1
2
Very
Unrealistic
Moderately
Unrealistic
1
2
Information
3
4
5
4
5
Moderately
3
3
Simple
Very Simple
4
5
Fast
Very Fast
4
5
Easy to
Very easy to
understand understand
3
3
3
Screen
3. If you could change it, would you present the requests
in a different way? How?
Report Screens
4. Would you change the way a form D is displayed in
the screen? How?
5. Would you change the way a foul time is displayed in
the screen? How?
6. Do you have any comments about the screens that
tell you to wait while the dispatcher reviews your
Figure B-6 Usability test. Questionnaire (5)
100
Very
Complete
Very
Cooperative Cooperative
Moderately
Very Difficult
Moderately
Complete
4
5
Moderately
Easy
Very Easy
4
5
Moderately
Realistic
Very
Realistic
4
5
Work Request Procedure
7. For each task below, do you have any comments about the procedure that we have used? How could we improve it?
7a. Request Form D
7b. Cancel Form D
7c. View Form D report
7d. Request foul time
7e. Cancel Foul time
7f. View Foul time report
7g. View track out of service report
8. Is the form D request procedure close to current
railroad operations? Do you have any comments about
it?
9. Is the foul time request procedure close to current
railroad operations? Do you have any comments about
it?
10. Write down any comments about a particular
problem that you had while navigating through the form
D or foul time screens.
Figure B-7 Usability test. Questionnaire (6)
101
Overall usability
1. Please rate the PID's ease of use for the following tasks
Very easy
Easy
a. Request train location
1
2
b. Request territory information
1
c. Request Form D
Difficult
Very Difficult
3
4
5
2
3
4
5
1
2
3
4
5
d. Cancel/Fulfill Form D
1
2
3
4
5
e. View Form D's under your authority
1
2
3
4
5
f. Request foul time
1
2
3
4
5
g. Clear Foul time
1
2
3
4
5
h. View Foul time under your authority
1
2
3
4
5
1
2
3
4
5
i. View Track out of service report (under foul time or
form D)
2. What additional features or information would you like
to include in this tool?
Task realism
3. Please circle your level of agreement with the following statement.
Strongly
Disagree
a. The tasks proposed in the experiment are close to
1
typical real interactions with dispatchers.
Strongly
Disagree
2
3
4. Would you include any other type of task in the
experiment? What tasks?
Figure B-8 System evaluation test. Questionnaire (1)
102
Agree
Agree
4
5
Usefulness and PID
improvement
5. Please circle your level of agreement with the following statement.
Strongly
disagree
Strongly
agree
a. If I had the opportunity, I would use the PID to
retreive train location information
1
2
3
4
5
b. If I had the opportunity and if it were permitted by
operating rules, I would use the PID to ask the dispatcher
for protection
1
2
3
4
5
Much lower
Lower
Same
Higher
Much Higher
1
2
3
4
5
6. Compared to current procedures using the radio or cell
phone, the work load using the PID was?
7. What safety concerns need to be addressed before
this device could be used in railroad operations?
8. List and comment on any features or requirements that
the PID must have before even considering to use it in
railroad operations.
9. Do you see any other potential uses for the PID ?
Figure B-9 System evaluation test. Questionnaire (2)
103
Not at all
important
Slightly
Important
Moderately
Important
Very
Important
Extremely
Important
1
2
3
4
5
10. How important is it to be able to have a wireless
portable printer to print information received from the
PID?
11. Please write down any other general comments on
how we should improve the PID?
12. Can you suggest a better name for the Personal
Information Device (PID)?
Figure B-10 System evaluation test. Questionnaire (3)
Situation awareness
1. Write down an available window of time to perform
the assigned task.
From:
2. What is the next train at your location? Is it delayed?
Train #
To:
Delayed:
yes / no
3. What is the maximum train speed allowed at your
location?
mph
4. For the next two trains at your location indicate their
direction of travel. Write the Train ID and circle the
appropriate direction.
Train
Train
Direction:
Direction:
East
East
5. Name the dispatcher in charge of the territory you are
in?
Figure B-11 System evaluation test. Questionnaire (4)
104
West
West
Appendix C.
Detailed experiment results
The following pages contain detailed results of the system evaluation test.
Each page of results is organized in four columns (time, error, situation awareness and
notes) and fourteen rows (one row for each task). Shaded figures represent total or subtotal
quantities.
"Time" column
"Time" column contains five subparts: "Task", "Work request", "Work cancellation",
"Information gathering (palm only)" and "Information gathering + extra time".
"Task" column contains information about the time spent at each task. If there are two time
intervals within a given cell it means that the test user visited twice the same task.
"Work request" and "Work cancellation" columns contain information about the time spent
during a work request or a work cancellation. Each time interval represents a single interaction.
When there are more than one time intervals, the last one represents the final and successful
attempt. The preceding ones will represent unsuccessful attempts. The "Type of screen" column
refers to the type of request as described in A.2 and the "Number of screens" contain the number
of such requests sent. When the PID is used, there is an extra line in each cell. It contains
information about the average time spent while filling the gaps in the appropriate screen and
twice the network latency.
"Information gathering" column contains the different information gathering requests used
during the PID test and the time spent for each request. Again these times are computed taking
into account twice the network latency and the average time spent while filling the gaps for each
request.
"Information Gathering + extra time" is just the total task time minus the time spent in work
requests and work cancellations.
"Error" column
"Error" column includes the amount of errors as described in 4.1
105
"Situation awareness" column
"Situation
awareness"
column contains
two subparts:
"Have
noted" and
"Have
remembered"
"Have noted" column contains the amount of information actually retrieved by the test user
either from the PID or from alternative sources when the radio was used. There are two lines in
each cell. The second line represents the ideal amount of information that should have been
retrieved according to the window of time when the work took place. The first line represents the
actual amount of information retrieved. The shaded line represents the relative amount of
information retrieved. "Territory information" column includes train dispatcher in charge of the
territory in which the work site was located, the rules that applied in that territory and the
maximum train speed around the work site. "Relevant trains" column are all the trains that
represented a potential hazard for the work crew, this is, trains that would go by the track
adjacent to the work site while the crew was working. "Updated train schedule" column refers to
the fact of knowing the real time train schedule with any possible updates. "Train delay" column
refers to the fact of knowing whether a train is delayed or not. If train 012 was due at View at
9:45am but it was 10 minutes late, knowing that it would reach View at 9:55am was a point
towards "Updated train schedule" and knowing that it was 10 minutes late was a point towards
"Train delay". Knowing the train delay immediately guaranteed knowledge of the updated train
schedule, but not the other way around.
"Have remembered" column represents the result of the situation awareness questionnaires
handed to the test users. It only makes sense when these questionnaires were actually handed to
the test users, this is, twice in each set of tasks.
"Notes" column
"Notes" column contains references to notes on the following page of each page of results.
A number is a reference to an explanation of the circumstances of the task. A letter is a reference
to the actual window of time used by the test user and the trains that he or she should have noted.
106
This page intentionally left blank.
107
09
r~0
~
8c
-
jQ~
U
..
CA_
5
-OD
-.
a
-
_
_
__~~~~
02
8h
C9
r--
-
k9
aa?
j-=pi
9900.
9
-J3
Dc
F?
r
0
pQ
a9
CL
'
W=
a
-
90
.
U
a
~
Sj
-
(i
8
_ R C,~J
8 :-3
~
__
a
_
a
4
ro
Task 1, User 2, Palm
'I
Notes
1. Negotiated time with dispatcher. This explains the longer time for this task. Two full FT
requests
2. Did not have foul time from task 3
3. With the window of time that this test user used, there were no trains at the work site.
He noticed that and that's why I have given 100% in situation awareness
4. Used 00:01 instead of 12:01 so he did not see the right trains. 1 safety error
5. Sent a wrong FT request that was not accepted but he never saw it. He sent a new one
which was also wrong (2 FT requests that should have never been sent). Then he
realized and sent twice a correct request (1 communication error).
6. Did not look for territory info in task 11. Used experience for task 12 and made 1 error
in territory info
7. One of the TI requests was used to check the answers for task 12.
109
trains
[09:30 - 09:55]: 012, 171
[10:05 - 10:56]: 093, 012,
WX305
c) [10:30 - 11:00]: WX305
d) [11:15 - 12:15]: no trains
e) [12:20 - 12:50]: 163
f) [13:40 - 15:40]: 163
g) [15:45 - 16:15]: 084
h) [16:30 - 19:00]: 177, 084,
815, 820, 817, 822, 819,
169
a)
b)
I
a
ii-
i4
-. 0
98
___Pt
Co3
8s
In
FN
U
rat
8j
09
0-go
; R
0
6
ONg
ia6
64-.
I
I
m
Task 1, User 3, radio.
I
Notes
1.
2.
3.
4.
5.
6.
Did not know train schedule around his work site. Asked for foul time (1 safety error).
Also 0% in situation awareness. The next train he knew about was 173 at 11:44 and he
was working between 10:15 and 10:35
Did not know train schedule around his work site. Asked for foul time (1 safety error).
Also 0% in situation awareness. The next train he knew about was 173 at 11:34 (time
without delay) and he was working between 10:30 and 11:00
Had to repeat date (1 communication error)
Did not know about train 173 and asked for FD (1 safety error)
Did not see train 163 at route 128 coming at 12:41 and asked for FT 12:40-13:10 (1
request that should have never been sent). He was granted FT 13:10-13:40 but he did not
know about trains in this window of time (1 safety error)
Did not send a FD request although he could have. 1 work request that should have been
sent
111
I rains
a) [09:30 - 09:55]: 012, 171
b) [10:15 - 10:35]: no trains
c) [10:30 - 11:00] : WX305
d) [11:30 - 12:30] :173
e) [12:40 - 13:10]: 163, 809
f) [16:00 - 18:001: 174
g) [15:45 - 16:15]: 084
h) [16:30 - 19:00]: 177, 084,
815, 820, 817, 822, 819,
169
a ce
cm
-.
0 rA
L4
p
ti 8
C
2
~
w
C')
4> -n
9
8
80
-
v8i3
CM
,
08
8
8
8
~ ~
-
i
Is-
~
-n
~
~
83J~
2
~~C
82888
~
8
8
0
I
~z
1
IL0
Task 1, User 4, Palm.
I
Notes
a) [09:30 - 09:55]: 012, 171
b) [10:00 - 10:40]: 093
c) [10:30 - 11:00]: WX305
d) [11:30 - 12:30]: 173
e) [13:00 - 13:30]: 809
f) [14:10 - 16:10]: 163, 175
g) [15:55 - 16:25]: 084
h) [16:30 - 19:00]: 177, 084,
815, 820, 817, 822, 819,
169
1. TI request should have been sent in task 5. That's why this test user has a 0 in TI
situation awareness for task 5
2. The first FT request was sent without expected duration (1 communication error)
3. The second FT was OK but dispatcher granted a different window of time. The user did
not accept it.
4. The third FT request was the same request that the second one. This time, the dispatcher
denied it and told the user that he could have a different window of time
5. The fourth FT was sent with the available window of time but without track number (1
communication error). The user noticed his error and he quickly sent a correct FT
request
6. Finally, the fifth FT request was sent with all the appropriate information and accepted.
7. Dispatcher answered with wrong info. User detected this.
I
113
Trains
M1
I
IIo
N
~I
Izt
I
8 0
0w
I
89-
aO
NO
___
90
JNc
idU
NNN
NN
10
LO1
10
O
s
4N
N
at. ca
Task 1, User 5, Radio
Trains
Notes
Did not notice train 093 that was delayed and could cause problems (1 safety error)
Could have asked for FT.
Task 4 does not apply. He did not have FT from task 3 so he could not clear it on task 4.
Could have asked for FD. Only one train in the required window of time
Task 8 does not apply. He did not have FD from task 5 so he could not clear it on task 8.
User detected wrong track given by dispatcher and the correction was made
immediately. But he did not know about train 809 and he accepted the FT (1 safety
error)
7. Did not know about train 163 and accepted FD. (1 safety error)
8. Asked for FD4 instead of FD23. Experience issue here. This user had never requested a
FD23 in real life.
9. He called the wrong dispatcher the first time (1 work request that should not have been
sent)
10. Did not write anything. Missing information so can't evaluate situation awareness
1.
2.
3.
4.
5.
6.
115
a) [09:30 - 09:55]: 012, 171
b) [10:00 - 10:20]: 093
c) [10:30 - 11:00]: WX305
d) [11:30 - 12:30]: 173
e) [13:00 - 13:30]: 809
f) [13:30 - 15:30]: 163
g)
h)
[15:45 - 16:15]: 084
[16:30 - 19:00]: 177, 084,
815, 820, 817, 822, 819,
169
Co4
_ _ _
I J
*1
.1
I
C"L
88
i
8
jR
ZS
=
r881
~~~
E
q
4
8;
g F,2
..p
t~tt~
--N_
8
!
rz
M
f7
JC,~1~L 0.Li
_
88p8
:9 R
ei
1
4
NN
00 q
e
as
IxI
~00
00
4m
TT -0l
-0
Task 1, User 6, Palm.
'a
Notes
1. Should not have sent this FT request. 012 and 171 at work site in opposite directions at
the same time. (1 work request that should not have been sent)
2. Sent a correct FT request that was accepted by dispatcher -but then he changed his mind
and forgot to cancel the request (1 safety error).
3. The work request should have been sent (1 work request that should have been sent)
4. User aborted the first FTCR transaction. The second FTCR-FTC was sent without a
given FT. The third was sent ok while he was on task4.
5. The first FT request was sent without track info. (1 communication error)
117
Trains
a) [09:30 - 09:55]: 012, 171
b) [09:56 - 11:00]: 093, 012,
WX305
c) [10:25 - 11:00]: WX305
d) [11:25 - 12:25]: 173
e) [12:30 - 13:00]: 163
f) [13:30 - 15:30]: 163
g) [15:55 - 16:25]: 084
h) [16:30 - 19:00]: 177, 084,
815, 820, 817, 822, 819,
169
T2 - Pal.
Time
k.I
Task
Work Request
Task
it
time Final
10:34:00
10:41:55
numbergathering
Init
Totaltime
Fin
time
0:07:55 10:39:04 10-39:04
10:39:55 10:41:20
FT (2). NL (4)
TolWie
tie
Work cancelation
numbTy
ero
of
lnit #me
scenscreon
Two
FT
FTAC
2
2
1
FTAC
1
0:01:25
LF
Final
Total
time
"Oenscr
on gawhering (pdim oly)
W
of
Type
mubrType
screen
esent Ofn
of
ren
Ti
TSW
number
of
sceens
1
1
Work
Insormation+
extra time
Tine
Work
He
rqueg
CM
S
Vtat
huld
have been NOT have erroT$rritory
bwsent
inyo
f
rOqufts
thtatethould
0:00:25
0:00:48
R
noted
Have remembered
Updaat
e Td n
Train
ray
risSchedule deaj
Trais
4
4
1
1
1
1
Relevant
Tan
Trm
0
1
1
1
Notes
WidwTrtryTan
Window Terrtory
o ie
Wo
r
Trains
d
Trayi
delay
1
0:02:08
0000
:
10:41:55 10:43:16
Situation awareness
E=
0:01:21
01
:
2100%
0
101
:00%
1
23
2
FTAC (1). NL (2)
_:0:
10:43:16 10:49:24
0:00:16
tO5l
0.0000
0:06:08
00|00,Q
3
10:49:24 11:02:52
0:0-08
0:13:28 11:00-05 11:00:05
11:00:29 11:02:52
4
FT (2). NL (4)
I__
0=0.
0:02.06
oiAC
2
4
1
0:00:25
1
0:00:48
1
1
0-0113
0:0025
0:00:48
0:00
Ti
TSW
0-01:13
8::8
0:00:00
a013.:29,.2
11:02:52 11:07:51
1
0M.0
FT
LF
0:02:23
00105-
T
TSW
0:04:59
1
2
2
".0
1
100%
2
2
5
5
2
2
0
1
2
2
4
b
I__
2
2
D%
0
1
110%
2
2
5
100%________
100%_________
c
___________0___
0
2
2
2
4
0
1
0%
100%
50%
0%
1
5
11:07:51 11:15:00
00415S
0:07:15
.000O
0
8:08:00
TSW
TS
6
1
3
807:iS008:80
___
11:15:05 11:16:47
0:01.41
11:16:47
0:09:59 1123:36 1126'28
0,02.52
8
FD4 (1). NL (2)
11:26:46 11:29:02
00.1W
0:02:16
11:29:02 11:32:35
0:03:33
1
2
0:00:39
0027
11:15:36 11:16:01
0:0025
FTCR (1). NL (2)
0:00:12
7
11:28:46
8:0:5
0:0048
FD4
LF
FOATE
FTCR
FTC
0:07:15
_
_
_
_
_
_
_
_
7
c
5
_
_
1
2
1
T
TSW
1
1
80:010
0:00:25
0:00:48
0.01:13
0:06:_
0OI0
600)09
0:17:19 11:44:09 11:45:59
11:47:29 11:49:37
F04 (2). NL
11:49:54 12:02:52
(4)
0:17:1
0:12:58 12:01:09 12:02:19
0:01:50
0:02:06
12:02:52 12:04:32
NL
(2)
FD4
IF
FDATE
2
6
2
FT
LF
FTAC
I
1
1
1184
0:01:10
0:0103
0125:1
0:02.23
14
- 41&,"
Average
1:49:16
tow
FD4 (1).
NL(2)
0:00:48
0:00:13
4
4
1
1
1
1
0
1
1
1
100%
I00%
190%
0%
15%
_
_
_
_
_
d
0:00-14
FD4
LF
FDATE
FTCR (1). NL (2)
0:0012
I
1
2
0:00:52
1:919:
0:23:10
II
000:
0:0103
FTCR
FTC
I
1
1
0:00-25
0:00-25
2
0:01:36
FDR
Ti
TSW
SF
1
1
1
1
I
1
1
0:00:25
0:00:25
0:00:48
0:00:25
8:9595
0:00:12
0:00:12
Ti
TSW
FDR
FTR
1
2
1
1
0:00:25
0:01:36
0:00:25
0:00:25
*0241.i
1
MvFT
0:15:04
2
2
2
2
0
1
0%
100%
100%
0%
1
1
FTR
TST
0
1
1
Ti
2
0:0000
12:03:59 12:04:13
0:0:16
TSW
8:090
0:01:40
0:18:44 12-.2025 12:22-49
1
1
FOR
13
12:04:32 12:23:16
TSW
TS
0:01:44
12
FT (1).
_
0:00:52
10
11:32:35 11:49:54
_
1
2
9
11
6
1
4
1
4
0
,11:37
10%
4
4
O
0:1:8
100%
5
5
_
1:26:03
_
1
__2_
1
1
00%
1
1
100%
1
1
10
1
1
1100% 100%
_
3
-
0
I
1
1
0
1
1
100%
10
100%
1
1
4a"
I*A0
6.9
1
10
1
1
1
1
100.0% 100.0% 100.0%
1
1
1
10
1
1
9
100%
60.0% 100.0%
0.0%
100.0%
7.0%
0.0%
Task 2, User 1, Palm.
I rains
Notes
1. Sent a FT request with wrong time. Immediately noticed the error and sent the correct FT
request (1 communication error)
2. FTAC request in this task had no effect. He used the 'back' button and read again the
'please confirm FT' screen. He tried to confirm once more the FT of task 1, but since it
was already effective nothing happened
3. Because of the error mentioned in note 2, he received a screen asking him to contact the
dispatcher by radio. This is why he did not clear the FT with the PID as it was requested
(1 communication error). He said that he would have done it with the radio.
4. Trains 805 and 093 go in the same direction. Could have requested FT (1 work request
that should have been sent)
5. Sent twice the same FT request. (1 communication error) The dispatcher granted both of
them and the test user accepted the last one. This should have been a FD request
6. Did not remember train IDs although he remembered that one was Amtrak (west) and
another MBTA (east). He made a mistake in one direction. 2 out of 4 in train and
direction
7. Did not check train status. He checked entire schedule so, although he got the updated
schedule, he could not tell if 812 was delayed. He thought it was on time.
8. He found a window of time with no trains. 100% in situation awareness
9. He sent a FD request for 15:30. Dispatcher granted this FD, but he did not accept it and
sent another one for 15:25. This second one was also granted and this time he accepted
it (1 work request that should not have been sent)
10. Note how he spent more time gathering information. He checked for delays, for other
track out of service, for territory info and for train schedule around work site.
11. He found a window of time with no trains. 100% in situation awareness.
119
[08:35
[09:05
[09:40
[11:20
[15:25
f) [16:20
g) [23:30
a)
b)
c)
d)
e)
- 09:05]:
- 09:35]:
- 11:05]:
- 12:00]:
- 16:25]:
- 17:30]:
- 00:30]:
171
805, 093
812, 173
012
no trains
084
no trains
-E
-
9
Ia'
I' a_
g
g
N-
0iOiO
IIN
8~8 o8
c
N Ir
0
-~
0
I-un
N
)
9
OD
_T
_v]
aa
01
C
0 0
It
e -
Nt
IV) V
CN
19N
o
r
'
08
Task 2, User 2, Radio.
'I
Notes
1. This user did not write down any train ID in the answer sheets. All the info we have is a
piece of paper where he wrote down some notes. Whenever possible, we used these
notes, but otherwise, the fields were not taken into account
2. His notes said that he could work after 902. He did not noticed delay of 093. There is no
info about 805. 0% in delay, 100% in direction and no data for schedule info
3. No info at all about trains. Had to repeat dispatcher name and then date. (2
communication error)
4. From the questionnaire we know that he knew about 173 and another train. This is still
not enough info to fill the fields of task 4
5. Asked a generic question about "traffic patterns". Got all the info he needed.
6. Had to repeat cancel time. (1 communication error)
7. Test user detected that dispatcher had answered with wrong info. That's why there are 2
FD requests and 1 FDC
8. From task 9 we know that he was aware of train 12 and 814. He also knew the train
dispatcher.
9. He found a window of time with no trains. 100% in situation awareness.
10. He asked for FT at 15:48. Two trains were coming (175 and 084) but he knew it and
asked the dispatcher if he could reroute them. He did not know about delay in 084. The
dispatcher granted a different time that he accepted.
11. He asked for FT at 21:05 or after 824 went by. Dispatcher informed him about the delay
of 824 and granted FT from 21:15 to 22:00. No info available about 823
121
I rains
a) [08:15 - 08:45]: 171
b) [09:10 - 09:40]: 805, 093
c) [09:40 - 11:10]: 812, 173,
807
d) [11:20 - 12:00]: 012
e) [14:00 - 15:00]: no trains
f)
g)
[16:30 - 17:15]: no trains
[21:15 - 22:00]: 823
if
OCR
a
p~
R8
0
~
9
R9
8
z
8~
8~~
pj~~2
P.
8
q
pP
)
w
tJ
-
)0
1
lipi
t:::-w
01
;?q
0)
F?
N)
Z)
-4
N)
M
co
-Z
0
5 q
N
F
N)
i
(A
N
M
c?
-4:
N. 0:
0
:
8
0
U
08
88 1
o op
0
8
8
P
-Li
-
.)
8
9
CA)-
9
am08
8
Task 2, User 3, Palm
Notes
1. The first FT request was sent without track info (1 communication error)
2. The first FTCR was never used. The second was sent without FD #. The third was ok.
3. He did not looked for trains at the right time, thus sent a request that could not be
granted by the dispatcher. 0% in situation awareness and 1 work request that should
have been sent
4. Looked for trains at 21:30 not 09:30 (this user had problems with AM/PM selection).
0% in situation awareness. Requested a FD at 21:15 that was not granted. During all the
time he thought he was using AM so he went o the next task (1 FD that should have
been requested)
5. This task has no meaning because of the errors in task 4
6. Test user detected that dispatcher had answered with wrong info. That's why there are 2
FD requests
7. With the first FTAC he accepted the FT. But he sent the FTAC twice so he got a
"dispatcher not online" message. To confirm that he really had the FT he used MyFT.
8. He did not know about TI while in task 12. He checked TI in task 13 but that's too late.
0% in TI task 12.
123
Trains
a) [08:15 - 08:45]: 171
b) [09:05 - 09:35]: 805, 093
c) [09:40 - 11:05]: 812, 173
d) [11:20 - 12:00]: 012
e) [14:10 - 15:20]: 175
f) [16:20 - 17:15]: 084
g) [21:15 - 22:15]: 823, 824
-Y
P1-
I
1
Co4
3
U.
3
I
I
I,
-
iI~
-- -
-
0
C4.
LUU
FN
C4
A--
ON
A
N
F
3
a
N
-
N
N
N
C4
B
3
3
3
I,
46
-
.
so a
C
NN
F4
Task 2, User 4, Radio.
Trains
Notes
1. Did not say how long he wanted to work. (1 communication error)
2. Accepted FT without knowing about one relevant train (1 safety error)
3. Had not noticed train 812 that was delayed and asked only for 173. Accepted FD
without knowing about one relevant train (1 safety error)
4. Had not noticed train 812 that was delayed and asked only for 173.
5. He checked train 012 status. 100% in train delay in sit awareness
6. He checked train 084 status. 100% in train delay in sit awareness
7. He found a window of time with no trains. 100% in sit awareness
8. He checked train 823 status and asked for FD after 823. He did not know about train 824
being late
125
a) [08:15 - 08:45]: 171
b) [09:05 - 09:35]: 805, 093
c) [09:37 - 10:57]: 812, 173
d) [11:20 - 12:00]: 012
e) [14:05 - 15:05]: 175
f) [16:30 - 17:30]: No trains
g) [22:10 - 22:55]: 824
(include also 823 since he
checked for its status)
I
I-
I
~
1-4
N
-
"allI
~
5NN
N
NNN
66 00
NNm
co
00
LO
r-
c
N
--
-
C4
U. 9
C
V
0
Task 2, User 5, Palm.
I
Notes
1.
2.
3.
4.
5.
6.
There was only one train. He could have sent the FT request (1 work request that should
have been sent)
Since he did not have FT from task 1, task 2 had no meaning.
He could have sent the FD request (1 work request that should have been sent)
Tasks 6 and 7 do not apply since he did not have FD from task 4
Task 10 does not apply since he did not have FD from task 8
He found a window of time with no trains. 100% in situation awareness
127
Trains
a) [08:15 - 08:35]: 171
b) [08:40 - 09:10]: 832
c) [09:30 - 11:00]: 812, 173
d) [11:20 - 12:00]: 012
e) [14:00 - 15:00]: 175
f) [16:25 - 17:10]: no trains
g)
[23:30 - 00:15]: no trains
Coo
it~
ILO
__
U.o.
I ii
id
-
00
0-
6
-L
LO
N
go(
(Da
N
w..
C4
C-N
IQ
t;
in06
--
idb(i
g
g
-
0-
id
(
A
60
0
6
-
Task 2, User 6, Radio.
Trains
Notes
1. Sent FT request to wrong dispatcher (1 work request that should not have been sent)
2. Sent FT request (the one shown in table) to the appropriate dispatcher without desired
window of time (1 communication error)
3. Could have sent the FT request
4. Requested FT but then he realized that he wanted FD. (1 work request that should not
have been sent)
5. Asked for two train status. One of them was 173 (ok) the other was not at the work site.
Got confused when looking at the MBTA schedule and wrote down a wrong train ID.
Still he got the desired update for 173
6. Did not send desired window of time (1 communication error)
7. Dispatcher granted wrong track. He noticed this and asked again for FD. That's why
there are 2 FD requests
8. Accepted FD without knowing about train 012. (1 safety error)
9. Asked for 814 status not 012.
10. Sent FD without desired window of time (1 communication error)
11. Accepted FT without knowing about train 084. (1 safety error)
12. Sent FD request without window of time (1 communication error). Found a window of
time with no trains 100% in train sit awareness
129
a)
b)
c)
d)
e)
f)
g)
[08:10
[08:45
[09:35
[11:20
[14:03
[15:55
[01:00
- 08:40]:
- 09:15]:
- 11:05]:
- 12:00]:
- 15:03]:
- 16:30]:
- 01:45]:
171
832
812, 173
012
175
084
no trains
Appendix D.
Form D
100
NORAC UOVEM.NT PERMIT FORM D
FORM D NO.(S)
FORM D NO.
DATE__I
DELIVERED TO
TO
/-
FORM D CANCELLED
TIME
DATE
OSPR
1. TEMPORARY
SPEED RESTRICTIONS
2. OPERATE
ON
ON
ON
IN
_
DWZTIMM.)DOT
TRK BETWEEN
TRK
TRK
3. TRAINS
SPEEDSIN
BETWEEN/AT
TRK(S)
LINE
OR TRACK
BETWEEN
BETWEEN
-
FTWN
AND--
AND
DSPR
DSPR
DSPR
AND
AND
PE N
PSl EE
TIME
TIME
TIME
CARS AHEAD
SIGNAL(S) AT
4.
TRK OUT OF SERVICE BETWEEN/AT
TRK OUT OF SERVICE BETWEEN/AT
LINE
TRK OBSTRUCTED FOR MAINTENANCE BETWEEN
5.
6. NON-SIGNALLED DCS RULES INEFFECT ON
TRK(S) BETWEEN
7. INT AND CP SIGNALS OUT Of SERVICE ON
TRK(S) AT
ON
8. REMAIN AT
9. OPERATE AT RESTRICTED SPEED ON
TRK TO
10. TBS INSERVICE AT
TRK(S) BETWEEN
11. CSS RULES OUT OF SERVICE ON
TC PROCEED PAST STOP
INCHARGE OF
INCHARGE OF
AND
AND
TRK UNTIL ENGINE ARRIVES TO ASSIST
WHERE TRAIN
IS DISABLED
AND
12. PROTECT CROSSING(S)
13. OTHER INSTRUCTIONS/ANFORMATION
TRAIN
DISPATCHER
TIME EFFECTIVE
Figure D-1 Form D
130
M.
A brief explanation of the use of the different lines of a Form D follows (see rules 160-173).
In brackets it is shown the rules that apply for each line. For more details refer to the appropriate
rule in the NORAC Operating Rules book.
1 [175]: Speed restrictions. Train Speed Restriction Bulletins (TSRB) are used in place of
line 1
2 [400,402-405, 502, 803, 805, 806, 808]: Direction of travel. Written to give authority to
track cars to operate on a specific track between two interlockings.
3 [803, 805, 806, 807]: Written to inform track cars about trains or track cars ahead. A track
car is allowed to move behind trains, never in front of them. The second part of line 3 is used to
give permission to pass a stop signal. Rule 241 is usually used in place of second part of line 3.
Some dispatchers use line 3 and not rule 241.
4 [132-134]: Track goes out of service in charge of some employee (flagman/conductor/
foreman).
5 [132, 135]: Rebuild grade crossing without disturbing the track. Just nearby road.
6,7 [406]: Form D Control System (DCS), Control Point (CP) (see rules 400).
8,9 [137]: Used when a rescue train is heading towards the train being rescued.
10 [174]: Temporary Block Station.
11 [561]: Cab Signal System (CSS).
12 [138]: Used when a grade crossing malfunctions.
13 [132, 177, 400, 404, 406, 506, 507, 805, 806]: General purpose. Used for example to
describe where barricades are.
The lines that are mostly used by dispatchers are 2, 3 and 4. Lines 2 and 3 are issued to track
cars and work extra trains. Line 4 to repair crew foreman, flagmen and point conductors.
131
References
Basu, S. (June 1999). Real Time Simulation of Rail Dispatcher Operations. M.S. Thesis at MIT.
FRA report. (June 1999) Unpublished Presentation Prepared at John A. Volpe National
Transportation Systems Center.
Ditmeyer, S.R. and Smith, M.E. (April 1993) Data Links and Planning Tools: Enhancing the
Ability to Plan and Manage Train Operations. Rail International, pp 69-77
Kirwan, B. (1992) A Guide to Task Analysis. Taylor & Francis.
Lestime H. (June 1998) ETCS. Development of Train Control Systems for European High-Speed
Lines. Rail International Tokyo Seminar.
Leveson, N. (1995) SafeWare: System Safety and Computers. Addison-Wesley.
Malsch, N. (June 1999) Design and Testing of a Railroad Dispatching Simulator Using DataLink Technology. M.S. Thesis at MIT.
Nielsen, J. (October 1994) Usability Engineering, Morgan Kaufmann Publishers.
NORAC Operating Rules (January 1997)
Roth, E.M. and Malsch, N. (March 1999) Understanding How Train Dispatchers Manage and
Control Trains: Results of a Preliminary Cognitive Task Analysis. John A. Volpe
National Transportation Systems Report DOT-VNTSC-FRA-99-X
RWP Manual (March 1997). Northeast Corridor, Amtrak Roadway Worker Protection Manual.
Sheridan, T. (1992) Telerobotics, Automation, and Human Supervisory Control. MIT Press.
SOFA Working Group. (October 1999) Findings and Recommendations of the SOFA Working
Group.
Wojanowski E. (June 1998) Development, Testing and Validation of New Train Control
Systems. The ERTMS Project. Rail International Tokyo Seminar, pp 45-50.
Web pages:
Title 49-Transportation.
FRA. www.fra.dot.gov/o/counsel/reas/cfr/part/49CFR214v1.htm
Chapter II-Federal Railroad Administration, Part 214-Railroad Workplace Safety.
Java. java.sun.com
Neopoint. www.neopoint.com
Palm. www.palm.com
Palm VII description. www.palm.com/products/palmvii
Palm VII white paper. www.palm.com/pr/palmvii/7whitepaper.pdf
Perl. www.perl.com
Qualcomm. www.qualcomm.com
Web Clipping documentation www.palm.com/devzone/docs.html
132