30 Advances in Communications-Based Train Control Systems
in [17], a test track connected to the rolling stock manufacturer plant was used.
e test track was used by the rolling stock manufacturer for several other projects
at the same time.
2.11 On-Site Tests
2.11.1 Post Installation Check Out
Before functional testing can begin, verication of the hardware installation is per-
formed on each and every piece of equipment of the CBTC. For instance, cable and
wiring, grounding, and power to the equipment are tested in what is called PICO
test. is test is performed for each piece of equipment and constitutes the transi-
tion between the installation phase and the testing phase.
Even though this test targets hardware verication, each equipment is booted in
order to verify that the operating system on CC, ZC, and ATS works properly and
the identication of each equipment is correct. In addition, the network congura-
tion may also be tested. e current software version at the time of the PICO is
installed for the CC, ZC, and ATS in preparation of function tests. e software
version used during PICO is the factory version at the time of the test; it does not
have to be subject to FAT beforehand as no functional test is performed.
is test starts with the rst equipment being installed on the property and
continues throughout the project. Once a part of the system is in revenue service,
care should be taken with PICO because, though very unlikely, adding equipment
on the network may aect part of the system in revenue service. To mitigate the
risk of service disruption, after one part of the CBTC system is in revenue service,
PICO tests are performed during nonrush hours.
2.11.2 DCS Tests
e DCS contains two parts: one for the wayside network between equipment in
technical rooms and the control center, and the other for the radio system which
may also include a separate wayside network system.
2.11.2.1 Wayside Network Tests
Among the dierent CBTC subsystems, the rst subsystem to be installed and
subject to test is the DCS. To perform testing of the DCS, ber optic between
locations must be installed and veried by the installation team. In the techni-
cal rooms, network switches are installed and PICO tests performed beforehand.
e network management system (NMS) that administrates the network and is
provided by the network supplier must also be present before network tests are
planned. Tests on the network may include the following:
Testing Communications-Based Train Control 31
Checking of the conguration of each switch
Verication of connectivity
Verication of data transfer
Verication of NMS capability
Failure scenario of one node to test reconguration of the network
Latency tests
roughput tests
During the DCS factory tests on the network, the same tests are performed but on
a simplied version of the system with far fewer switches. e factory conguration
is supposed to be representative of the on-site network.
Ideally, PICO tests of the network equipment are performed rst, then the net-
work is tested before performing PICO of the other CBTC equipment (CC, ZC,
ATS) so that communication between equipment can be checked during PICO.
2.11.2.2 Radio Tests
e radio tests are dependent on the type of radio being used on the project. Where
the radio system uses a dierent wayside network than the wayside network used
for other communication between technical rooms, the radio wayside network is
tested with the same method as explained in the previous paragraph. After the
radio wayside network is tested, radio access points are subject to PICO test that
includes a power emission test.
Following radio wayside network and access point PICO tests, the radio system
tests are performed. First, radio coverage is veried using a train equipped with
CBTC. In most CBTC projects, the radio system uses redundant architecture to pro-
vide redundant paths for the communication. Redundancy may be both on board the
train where there is a radio system at each end of the train and on the wayside where
access points may have several frequencies. Where there is frequency diversity, access
points of each frequency are installed alternatively along the tracks. A radio tool on
board the test train is used to measure the electromagnetic eld with the radio link.
On some projects, the radio tool can also be used to send, almost continuously, data
packets through the network to monitor the number of packet losses. Both ends of
the trains may be connected to the tool so that the tests are performed in parallel for
each end. In order to verify radio coverage, the rst test is done with the access points
of only one frequency. Access points for other frequencies are turned o. is test is
repeated for each frequency. When performing this coverage test, it is preferable that
the train runs at a low speed. is test also veries that the transition between access
points is performed seamlessly. e worst-case conguration for radio coverage may
be identied and tested. It corresponds to a specic location where access points can be
far apart and there may be one or two masking trains between the train under test and
the near access points. Test at maximum operating speeds is also performed. Finally,
radio coverage with both train antennas and all access points is veried everywhere.
32 Advances in Communications-Based Train Control Systems
Testing the radio system is very important to prepare future functional tests
of the CBTC system. Where there is a gap of coverage, functional tests other than
localization tests are very dicult to perform. Radio tests can be done with a train
that is not controlled by the CBTC, meaning that it is possible to test the radio
system with a train in revenue service running in the bypass mode in between other
revenue trains. Depending on the CBTC product, radio coverage can be performed
before or after or during train localization tests. However, in most projects, train
localization is tested rst to help identify the location of radio coverage gaps.
2.11.3 Localization Tests
Localization tests verify that the train is able to initiate its localization properly,
and that the train maintains knowledge on its position on the entire network.
Train localization initialization is performed by running over several transponders
located on the roadbed, then an odometer system is used to compute the train posi-
tion based on the distance traveled from the last transponder. e odometer has
some uncertainty, typically a small percentage of the distance traveled since the last
transponder. To avoid having a large position uncertainty that diminishes CBTC
performance, transponders are located on the roadbed at maximum every thousand
feet. Each time the train runs over a transponder, the localization error is reset to
the minimum. In addition to an equipped train, the prerequisite to start localiza-
tion tests is to have the transponder installed on the roadbed.
Similar to the radio tests, localization tests can be done with a train in the
bypass mode where the CBTC is not controlling the train. Where the radio net-
work is not available or the interlocking is not yet connected to the CBTC, the
train may delocalize on diverging switches because positions of the switches are
unknown. Train localization is reinitiated soon after traversing a switch, thanks to
transponders being placed close to the switch area. Complete localization tests are
possible only after the switch positions are provided to the ZC, and the ZC com-
municates with the CC through the radio.
e localization function and radio test are the rst two tests to be performed
in the eld. ey are the foundation of CBTC. ough they represent only a few of
the CBTC functions, these tests constitute a large portion of the track access time
because the tests are performed on all tracks in both travel directions.
2.11.4 Integration Tests
2.11.4.1 Integration Tests: Internal to CBTC
e term “integration” is used when verifying that new equipment is connected to
the system and when checking functional communication between two subsystems.
is test is not always witnessed by the transit agency. To perform this test with
the CC, radio coverage must have been checked already. Depending on the status
Testing Communications-Based Train Control 33
of the communication network at the time of the PICO, the internal integration
test is performed as part of the PICO or later. For instance, this test veries that
the ATS is able to monitor the status of the equipment, and that commands can
be sent to the equipment, basic commands such as active unit switch over. Where
track access is very limited, the goal of this test is to prepare for functional testing,
which involves more resources such as test personnel and trains.
2.11.4.2 Integration Tests: External to CBTC
For hard-wired external interfaces to the CBTC, all inputs and outputs are tested
during this integration phase. e functional part is left aside as much as possible
to facilitate testing. For instance, all track circuits and switch positions are veried.
External interface tests can be performed independently from the localization and
the radio tests. Ideally, they are performed in parallel.
For data communication interface tests such as interface to an SSI, there
may be a dierence between the transit agency that prefers to test every bit
andthe CBTC suppliers who want to only sample the bit map. e argument
from the CBTC suppliers to perform only sample tests is that each bit was previ-
ously tested in the factory. e argument from the transit agency is that the fac-
tory tests are not witnessed and the conguration les may have changed since
the factory tests. In an ideal world where every change is tracked and retested in
factory, there is no need for testing all external digital interfaces. Because external
interfaces may involve another supplier, retest after every new version might not
happen in the factory and eld testing is then necessary. e decision is project
dependent based on how much each interface changes and how well the CBTC
supplier works with the external system provider.
2.11.5 Functional Tests
After the localization tests, the radio tests, and the interface tests, CBTC functional
test can begin. With the exception of the ATO, in an ideal world, the CBTC system
should be working properly. Indeed, all functional tests may be performed in the
factory, and, therefore, the functional tests need only to be performed to demon-
strate the functions to the transit agency for acceptance of the system. However,
in the real world, several months of testing and corrections are required. It is com-
mon that the transit agency requires that most tests be performed in the eld even
though they were already performed in the factory. When all functions work prop-
erly, performing site acceptance tests can be done within weeks.
e rst functional test to be performed is train tracking; it can also be done
with a train in the bypass mode not being controlled by the CBTC system. Tracking
by the ZC and the ATS is tested at the same time and can be considered a low-level
CBTC test. If the communication is ready and the equipment has been subject to
PICO, the tracking tests may be performed at the same time as the localization tests.
34 Advances in Communications-Based Train Control Systems
Following the train tracking, the CBTC basic functions are veried, although
at the same time all eld device positions are checked. For instance, the verication
that the CC does not let a train pass a red interlocking signal is performed for each
interlocking signal. Safety-related eld items such as interlocking switch position
or track circuit boundaries are veried. e test goal is to verify the presence of
the eld item in the database, and that the proper type of item has been set up in
the database. e actual position of the eld item in the database is only demon-
strated, which is not proven by test. Position of eld equipment in the database
is validated, thanks to a rigorous process of verication of the surveyed data and
database creation. Once all the basic functions are veried, more advanced tests can
be performed. Failure scenarios of the CBTC and ATS are performed. Also non-
safety-related functional tests are performed.
e art of testing CBTC is in choosing the functions to be tested along with
what needs to be repeated at every location in the eld. Because CBTC is such
a complex system, it is not possible to verify each function in all conditions at
every eld location. Tests must focus on safety-related functions to build con-
dence in the system. Factory tests are not sucient to provide enough condence
to the transit authority to let a system start revenue service without witnessing
on-site that the system behaves in a safe manner. erefore, all eld items related
to safety such as interlocking areas and all safety functions such as work zone
restriction should be tested. e dilemma about how much to test starts with
safety functions that are not related to the database, for instance, slow speed
order and work zone. ere is a near very large number of slow speed order, speed
selection, and start and end points. How many slow speed order tests to conduct
depends on the design of the system so the CBTC supplier should indicate the
type of test to perform. It is common to perform a slow speed order test for each
ZC, where only one test should be sucient because the same software runs on
every ZC; only the database changes from one ZC to another.
Regarding the non-safety-related functions, minimum tests are performed to
limit track access. For instance, the test to open and close the train door from
the ATS when the train is berthed at platform does not need to be done for each
platform. However, the safety-related function to check that the CC enables door
opening on the proper side of the track and only within the platform boundary is
performed for each platform.
Most of the CBTC issues found on-site are not related to any preidentied tests.
e tests that verify the CBTC requirements have already been performed in the
factory, and, therefore, it is unlikely that a new error that cannot be discovered in
factory is found on-site. Special tests that were not identied during development
of the factory and eld test procedures, because they do not correspond to any
requirement, are where most issues are detected in the eld. It is important to have
ocial procedures to use during testing, but most issues will not correspond to a
specic test step in an ocial procedure. e majority of the problems are found
during the rst runs using CBTC and are evident; for instance, the CC does not
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.129.218.69