Testing Communications-Based Train Control ◾ 25
2.8.1 Factory Test Goals
e goals of the factory tests are described in [1]. Most important ones are sum-
marized below:
◾ Test all internal interfaces: All messages including commands and control
between ATS and CC, ATS and ZC, and CC and ZC are tested with real
equipment. When real equipment is used, the term “tests on target equip-
ment” is employed. However, when the actual software is run on a machine
that only emulates real equipment, the term “test on host machine” is used.
◾ Test every function of the CBTC: Based on the system functional require-
ment, all functions are tested at a minimum of one location on the line.
◾ Test external interfaces as much as possible: Interface between the ZC and
the wayside conventional signaling system needs to be tested completely. e
most numerous interfaces concern the ATS, which needs real or simulated
systems to exercise the interface in the factory. e CBTC supplier may
develop those simulators based on their knowledge of the external system or
the simulator may be provided by the supplier of the external system.
◾ Perform failure scenarios, especially those which are dicult to perform on-
site: for instance, using simulated equipment allows for corrupt messages not
possible on-site with the real equipment.
◾ Support eld testing by reproducing issues: e eld team’s goal is to demon-
strate that the system works properly and not necessarily to investigate issues.
Once an issue has been detected on-site, it is reported to the factory test team
that reproduces and analyzes it with the help of the designers and developers
who are available in the same oce.
2.8.2 Factory Setup
It is very important that the system factory setup include real hardware for each
subsystem. It should include the ATS servers, CCs for checking redundancy, and ZCs
for checking redundancy and handover between ZC territories. e factory setup
should contain at minimum two real CCs and two real ZCs. Note that during the test,
trains are able to run over the complete line, but as there are only a few real ZCs on the
factory setup, the ZCs for the zone under test are selected to be the real ZCs, whereas
the others are simulated. If the project includes a Solid State Interlocking (SSI) or a pro-
grammable logic controller for the interface to the interlocking, then they should also
be included. A good practice that is required for large projects is to have a complete fac-
tory setup on-site. It allows eld teams to run pretests before using track access and also
for all personnel involved in the project to become familiar with the system (training,
visits, etc). It can be used for regression verications witnessed by the transit agency for
each new version. ough the investment cost is signicant, it is a valuable asset during
the project and it can be handed over to the transit agency after the project.
26 ◾ Advances in Communications-Based Train Control Systems
2.8.3 Different Types of Factory Tests
2.8.3.1 Product Factory Tests
As discussed earlier, CBTC suppliers use products that are likely applied to several
projects at the same time. e product team uses a virtual line that includes all pos-
sible track layout congurations. e database used is therefore dierent from the
database for a specic project. Tests at the product level may be very detailed; they
test functions that are not part of the system or subsystem specications known to the
transit agency and include failure scenarios that are very low level. e product team
is also in charge of verifying that the software runs properly on the target equipment.
2.8.3.2 CBTC Supplier Internal Factory Testing
Factory testing starts with the rst version of software even before the design is nal-
ized and the nal database is produced. Prior to the factory acceptance test (FAT) wit-
nessed by the transit agency, the CBTC supplier runs all the tests, completes reports
that describe all known anomalies, and provides them to the transit agency. Based
on the report, the transit agency may decide to hold or to postpone the witness tests.
2.8.3.3 Factory Acceptance Test
e FAT is a major check on the project status and provides a preview of the suc-
cess rate for the rest of the tests to be performed. It is performed on a software
version that is nal as much as possible, considering that subsequent eld tests will
help identify problems, and that a few remaining design issues may still be open.
Depending on the project, the FAT is witnessed by the transit agency anywhere
from a few days up to a few weeks.
A FAT may be required for each subsystem before a system FAT. However, in
most cases, a witnessed subsystem FAT is done only for the DCS.
Because the ATS is the interface to the system operator and it can be tested without
a real CC or a real ZC, a separate ATS FAT may also be required by the agency. Indeed,
all ATS functions can be tested using real ATS and simulated interfaces. Because most
advanced ATS function tests require the complete line and a large number of trains, it
may be preferable to only have the real ATS equipment during the ATS FAT.
2.8.3.4 Description of the Tests to Be Performed
First tests to be performed are related to the interfaces. is phase is sometimes
referred to as integration testing because it veries all commands and all controls
between the real equipment. is rst phase is performed before proceeding to func-
tional tests. is phase may be internal to the CBTC supplier as it does not verify any
functional requirement. en, the core CBTC functions, such as train localization,
train tracking, and movement authority enforcement, are tested. Someofthe core
Testing Communications-Based Train Control ◾ 27
function tests need to be repeated at all locations. For instance, the train localization
should be performed on the entire line in each direction and going over each cross-
over. Finally, the most advanced and project-specic functions are tested.
2.8.3.5 Major Challenges of Factory Tests
A major concern for the transit agency is that the factory tests be representative of real-
life conditions. ere are two obstacles to representative tests: (1) the technical aspect
of using environment simulators, especially where the DCS is very simplied in the
factory setup, and (2) the tests are performed by testers usually not familiar with train
operation and therefore may react very dierently than the future train operators.
A common issue for CBTC system testing is to assume that the factory setup is
responsible for a failure and to frequently reboot all the equipment to have a clean
starting point giving more chances for the test to pass. In operation, signaling systems
run continuously and cannot be rebooted. To cope with this issue, transit agencies may
require endurance tests over several days. Because the number of real CCs and real
ZCs is limited, endurance tests are still relatively far from real-life system endurance.
Successful witnessing of FATs is a prerequisite to the start of functional tests on-
site. At the end of the tests, some issues will be detected regarding implementation
or design. Deciding what issues need to be resolved before the software is sent on-site
is a delicate topic. CBTC suppliers tend to minimize the impact of issues, although
the transit agency desires that all known errors be corrected. Transit agency concern
may be to avoid wasting any track access by having conditions on the test due to a
software defect or due to the need of performing the same test again after an issue is
corrected. Another transit agency’s concern is to maintain a good reputation of the
project within the transit agency. If the software rst used on-site contains too many
errors visible to the train operators during the tests, the agency personnel may be
less than enthusiastic with the idea of using CBTC in revenue service in the future.
2.9 On-Board Integration Tests
2.9.1 Rolling Stock Characterization Tests
ough it is not part of the verication and validation, the characteristics of rolling
stock should be veried and/or determined through eld activities by the CBTC
suppliers. e transit agency and rolling stock manufacturer decide based on tests
and other considerations what is the guaranteed emergency brake rate and what is
the maximum acceleration rate on leveled track. However, it is not sucient for
the CBTC supplier to tune its train model used for proper ATO. CBTC suppliers
perform what is called rolling stock characterization tests. e train is controlled by
a special CC software. is special software sends commands to the train propul-
sion and brake system, and then speed sensors on board the train collect data about
28 ◾ Advances in Communications-Based Train Control Systems
the train reactions. After the tests, the data are analyzed by CBTC experts in order
to determine the train model characteristics. is activity requires several test cam-
paigns where results will be veried during ATO tests with the actual CC software.
2.9.2 Mechanical and Electrical Tests
e rst train or rst two trains are used as prototypes where the carborne equip-
ment is tted in the train for the rst time. is task includes verications of
the mechanical t into the car body such as checking alignment of all mounting
devices. Once the mechanical interface is veried and issues are solved, electrical
test verication is done. Electrical tests start with very low-level tests such as pow-
ering the equipment. All hardwire inputs and outputs are exercised using a special
CC software. Communication with other electronic systems on board the trains is
also veried. is prototype testing usually lasts a few weeks.
2.9.3 Static and Dynamic Post Installation Check Out Tests
Installation tests can be considered CC Post Installation Check Out (PICO) tests
where the hardware equipment and the installation are veried. is activity is per-
formed for each and every train using a special CC software dedicated to test along
with the rst version of the real CC software. In order to verify the speed sensors, a
small train movement is involved.
In most projects, all trains are tested with basic CBTC functions, including
ATO. Testing ATO on each train is very important because, as noted before,
the train characterization test was performed on a limited number of trains. e
parameters may have to be ne-tuned to manage the complete train eet.
To perform verication of CBTC core functions on each train, other equip-
ment, such as radio and ZC, need to be available for at least one location, for
instance, on a test track. Similar to the electrical tests described above, all hardwire
input, and outputs are exercised using a special software communication to verify
that the train was wired properly. Installing and checking CBTC equipment on a
train can be performed in a couple of days when there is no problem. A single test
shift is typically sucient for verifying basic CBTC functions.
2.10 Test Track
2.10.1 Use of the Test Track
In browneld projects, a test track is typically used for testing the CBTC system
prior to using mainline tracks. e test track may be used for several purposes:
◾ CC tests: To verify the design of the CC/rolling stock interface after the rst
on-board equipment has been installed.
Testing Communications-Based Train Control ◾ 29
◾ System tests: To test most CBTC functions.
◾ Car by car CC installation verication: To integrate the CC on each train,
each train is tested on the test track for core functions in order to verify the
interface between CBTC and rolling stock.
◾ Training: To train the train operators to control the train under CBTC.
etest track has to be long enough to serve this purpose.
◾ System regression tests: To test new CBTC software versions during the
deployment phase, as well as after the CBTC has started revenue service.
2.10.2 Test Track Equipment
IEEE recommendations for CBTC testing [1] provide a complete description of
the capabilities of an ideal test track. A test track must be equipped with all CBTC
equipment: Transponders must be installed on the roadbed, radio access points
must be installed near the track, and a network must also be deployed to have com-
munication between the CC and the ZC installed in the technical room. In order
to test most CBTC functions, an ATS server and a workstation must also be avail-
able, for instance, to set up a slow speed order.
Ideally, the test track layout includes all possible congurations. For instance,
all possible types of signals are present. A switch between tracks is also useful. It is
common that the test track database includes one or several virtual platforms to test
door operation and some of the ATS trip assignment functions. Virtual platforms
do not exist in the tracks. ey are only in the database for test purposes. e length
of the test track is a key element to determine what functions are testable on the test
track. To test the ATO operation properly, the train must have enough distance to
run at a speed close to the operating speeds on the mainline. Even if the test track
does not include all possible congurations, a test track is a must in browneld
projects to help avoid wasting mainline track access at the beginning of the project.
In greeneld projects, the test track is the rst section of track available for testing.
2.10.3 Location of the Test Track
e test track can be located in the yard area with a specic ability to be congured
as mainline in order to test the mainline functions such as ATO. Express tracks can
also be used as test tracks during nonpeak hours.
Another option is to use a test track outside the property of the transit agency.
With this option, track access is much easier than on the nal site, the tests can be
performed during day time, and the test track can be long and include switches,
grades, and any other congurations. However, travel is required for performing
the tests and transportation of rolling stock is necessary. Another issue with remote
test track is that the design and installation investment for the test track is not
going to be used in the nal system. In the driverless migration project presented
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.