Testing Communications-Based Train Control 35
release the brakes or the ZC does not provide the MAL. After the rst months of
debugging, the performance of functional tests is more likely to reveal design issues
than implementation ones.
2.11.6 ATO Tests
ATO is used in most CBTC projects. ATO tests are performed rst on the test
track to verify that the ATO software is able to control the train properly such as
maintain appropriate speed and make proper station stopping accuracy without
being overriden by the ATP function. To test every speed and every change of
civil speed, ATO tests should be performed on each track and in both directions.
During ATO testing, station stopping accuracy is also veried.
It is preferable to perform the CBTC basic functional tests in the ATO mode
rather than performing the test when the train engineer is controlling the train
under ATP supervision. Doing so, both the stopping point of the train and the eld
item locations are checked. As the ATO mode may not be available for testing at
the time CBTC basic functions are tested, the test may need to start in a manual
mode of operation.
2.11.7 ATS Tests
Except for integration tests when each command and control is veried, most ATS
functions require the other CBTC subsystems to work properly. Some main advanced
ATS functions include automatic train routing used for setting up routes and manag-
ing train junctions, and trip assignment based on the train operating schedule. For
driverless projects, the ATS is needed to perform CBTC functional tests and the proj-
ect schedule must be attentive to have all CC, ZC, and ATS from the factory ready
for eld testing at the same time. Because all ATS functions, except route setting
and interface testing discussed before, can be tested very well in the factory, specic
tests of the ATS can be limited on-site. e advanced ATS functions such as train
regulation are part of CBTC system tests where the CC and the ZC are also tested at
the same time. e route setting function is particular because a specic check must
be done for each interlocking signal on-site to conrm that the routes are set early
enough so that the test train does not have to slow down in front of a red signal.
2.11.8 Site Acceptance Tests
Depending on the project, the transit agency witnesses and approves results of
only the functional and external interface tests, or all tests, including the PICO
and both internal and external integration tests. e site acceptance tests are writ-
ten based on the system functional specications derived from the contract. All
requirements that can be tested on-site are tested, and additional tests identied by
the CBTC suppliers should also be performed. To meet the revenue service target
36 Advances in Communications-Based Train Control Systems
date, it is common practice for the rst version of the CBTC software to not include
all functions. Advanced functions, often related to the ATS, are pushed to a later
stage. Any nonurgent issue detected on the rst version is corrected in the version
that includes the advanced functions.
Prior to the site acceptance tests, the transit agency may want to witness a sam-
ple of the debugging phase of the CBTC tests in order to stay informed on the prog-
ress and to increase the transit agency knowledge of the system. is corresponds to
the phase where test procedures are checked before being performed ocially and
when issues are investigated and solved by the suppliers.
2.11.9 Shadow Mode Tests
A concept used in CBTC migration projects is to monitor the performance of
the CBTC system for an extended period of time, although it is not yet control-
ling the trains or any eld devices. is period is called “shadow mode,” “ghost
mode,” or “monitor mode.” All inputs are active and connected to the CBTC
equipment, but the CBTC CC is not controlling the train and the interlocking
system is not applying any commands from the ZC. is type of test starts prior
to starting revenue service and typically lasts several months. is phase helps
demonstrate the reliability and availability of the CBTC system, and it helps
build condence among the stakeholders for the project. When certication for
revenue service is approved, trains controlled by the CBTC without passengers
are introduced in between revenue service trains. Once the shadow mode period
is completed successfully, passenger revenue service can begin for the CBTC
system provided the safety certicated was obtained previously.
2.11.10 Reliability, Availability, and Maintenance Tests
2.11.10.1 Reliability and Availability Demonstration
e goal of the reliability and availability demonstration is to demonstrate, toward
the end of the project, that the characteristics of the system actually meet the con-
tract requirements regarding reliability and availability, measured in terms of mean
time between failures (MTBF), mean time between functional failures (MTBFF),
or other measurements dened in the contract.
In CBTC projects, the demonstration generally lasts at least 6 months and
begins immediately after revenue service has started on the entire line. All equip-
ment need to be installed and turned on continuously for the test to be representa-
tive. Six-month duration is the minimum length in order to measure the reliability
with a good level of condence. e success of the test may be a condition to exit
the warranty period, which is typically 2 years after the last CBTC equipment has
entered revenue service.
Testing Communications-Based Train Control 37
e availability is calculated using the total test time minus the observed
downtime due to CBTC failures divided by the total test time. Denitions of MTBF
and MTBFF are the number of failures and the number of functional failures over
the accumulated operating time for one type of equipment. e denitions actually
apply to the entire life of the system and would not be representative of the system in
a 6-month test. erefore, it is common that CBTC contract requires a specic cri-
teria based on a one-sided chi-square test with 90% or 95% of condence level. is
test has several other names such as goodness-of-t tests. Both the CBTC supplier
and the transit agency should agree on the terms and conditions of the test when
signing the contract or before starting the demonstration.
2.11.10.2 Maintainability Demonstration
Maintainability is the ease with which a product can be maintained. Maintainability
demonstration is performed after the transit agency maintenance personnel have
been trained. It can be performed before or after the system has started revenue ser-
vice; for instance, it can be done during the reliability and availability demonstra-
tion. e maintainability demonstration serves two purposes: verify that the mean
time to repair (MTTR) meets the contract requirement and show that the training
and maintenance manuals are adequate.
In order to verify the MTTR, the equipment to be tested has to be agreed by the
CBTC provider and the transit agency. One approach is to use a statistical method
for sampling the population of CBTC items. Producer and consumer risks are used
to determine a sample size. Once the number of items to be tested is calculated,
the agency and the supplier choose randomly the equipment to be tested. Another
mathematical method of choosing the tests to be done is explained in [18]. is
method is based on the failure rates and the number of identical items in the sys-
tem. In this method, the agency can decide on testing the items that will represent
a high percentage of the maintenance actions.
When the test is performed, a failure is introduced on purpose and the repair
is done by the transit agency maintenance personnel without the assistance of
the CBTC supplier team. It is a good practice to have several teams of mainte-
nance personnel doing the same corrective action and use the mean repair time
for the same correction. e results are gathered in a report after the tests, and an
MTTR is calculated based on the mean of the repair duration observed on-site.
One of the possible positive outcomes can be updated maintenance procedures.
As suggested in [4], MTTR is usually required for the complete CBTC system.
An issue with the mathematical approach proposed in [18] is that as the number
of CCs is much larger than the other subsystems, most of the maintenance will
thus be on the CC and the mathematical method results in choosing only CC
equipment. e analysis should be performed subsystem by subsystem to avoid
this issue.
38 Advances in Communications-Based Train Control Systems
2.12 CBTC Test Duration
e duration of the eld CBTC testing phase depends on various factors, and it
is not possible to dene test duration without knowing project specics. However,
based on the examples from projects in the last decade in dierent countries by dif-
ferent suppliers, a range of duration is provided in this section.
As discussed previously, CBTC projects are of two types: greeneld projects on
new lines and browneld projects on existing lines where revenue service must be
maintained during the project. For greeneld projects, the total duration of the proj-
ect can be planned in as little as 2 years, whereas the minimum time for a browneld
project is about 5 years. CBTC projects are often more dicult than anticipated
and important delays are very common, especially with browneld projects where a
5-year project is considered successful when executed in less than 7 years.
e experienced delay between the rst CBTC eld tests and the revenue service
is at least 1 year. For browneld projects where CBTC starts revenue service on a
section by section basis, the testing phase for the full line may last up to several years.
In order to have an earlier revenue service date, a common practice is to post-
pone the inclusion of advanced functions in the rst CBTC versions used for reve-
nue service. e advanced functions and subsequent changes are tested after the
CBTC starts revenue service. erefore, in addition to xing issues discovered dur-
ing rst months of revenue service, the supplier performs tests for these advanced
functions. It is worth noting that in many projects, CBTC testing is not completely
over when CBTC starts revenue service. Converging to the nal error-free service
may take as much time as original eld testing.
2.13 Constraints on Field Tests
Testing CBTC is a dicult task for several reasons. e most common issues
encountered are as follows:
Diculty to obtain track access: is is especially true on browneld projects
where the line is already in revenue service. e tracks are used during the
day for revenue service operations and during the night or o-peak times
for maintenance. For greeneld projects, track access is relatively easier to
obtain, but still it is competitive because all other subsystems may also need
the tracks to complete their installation and tests.
Coordination with the installation: During integration tests, where eld ele-
ments are veried one by one, a prerequisite is of course the equipment instal-
lation. e long-term planning, including the equipment installation order,
must be reviewed carefully to match with the test planning. Because CBTC
projects are very large with many stakeholders and companies involved,
itmay happen that testing is planned and testers discover that the equipment
Testing Communications-Based Train Control 39
to be tested is not installed. Communication between installation and test
teams is very important and usually requires some adjustments at the begin-
ning of the project.
SSI interface: CBTC can be used as a standalone system, or it can be over-
layed over conventional signaling system. When the CBTC system is over-
layed over a conventional signaling system, the system is considerably more
complex and requires more testing but the major impact is the potential delay
of the interlocking deployment. Renewing a relay-based interlocking with an
SSI is a challenge. Adding to this challenge, the new interlocking functions
that manage the CBTC system make the SSI project very dicult and sub-
ject to potential delays. CBTC functions need the interlocking to be tested
completely, and, therefore, any delay in the interlocking project may directly
aect the ability to test the CBTC system.
Other common issues that may impact the testing are as follows:
FAT: It is required that the FAT be successful before tests can be performed
on-site. Depending on when the design is nalized and to a lesser extent
depending on the eorts on factory tests by the CBTC supplier, the FAT may
be delayed which has the potential to delay the beginning of eld tests. Note
that a delay in nalizing design might also aect installation.
Support from factory: An important factor in the success of eld testing is the
ability for the eld team to obtain support from the factory test team and the
designers. During the eld testing phase, the eld team identies and reports
issues to the factory team. e factory test team then analyzes the issues and
xes them in a new version; help from the designers may be necessary. New
versions of software and patches are frequent and required to converge to
error-free software. e time delay between detection of an issue and the next
software version containing the x are critical and dependent on CBTC sup-
plier factory teams. Projects that are linked to special events such as Olympic
Games cannot be delayed and therefore are priorities for the company. While
a priority project is being taken care of, other projects might suer from a
lack of resources.
2.14 Conclusion
CBTC technology is used by transit agencies all over the world mainly for its abil-
ity to minimize headway between trains and for safety through continuous speed
control. It is used in most new urban transit lines and also for renewing signaling
systems of existing lines. As for every large and complex engineering system, test-
ing of a CBTC system is very challenging. Fortunately, CBTC systems are able to
be tested almost entirely in the factory. Despite the factory testing, many eld tests
..................Content has been hidden....................

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