VERIFICATION AND VALIDATION PROCESS OF A RECENT

MEGA SIZE METRO PROJECT

Ir Rodney Ng, BSc, BEng (Hons), MSc, MHKIE, Tres Engineering Consultants Sdn
Bhd
Ir. Lim Lee Cheng, BEng (Hons), BEM, MIEM, Tres Engineering Consultants Sdn
Bhd
Poh Kok Peng, BEng (Hons), Tres Engineering Consultants Sdn Bhd

SUMMARY
The establishment of a Requirements Management Framework is instrumental to ensure all Contractors can
deliver a fully compliant system to their respective Specifications to ultimately meet the Employer’s Requirements
(ER). The Framework includes the management of the Contractors’ Verification and Validation (V&V) processes
for full compliance checking. Typical key processes within the Framework are Mapping of Employer’s
Requirements(ER) and Contract Specifications, Decompositions of requirement clauses, Gap Analysis, Change
Control, Requirement Database setup, V&V audits, Review of Contractor V&V submissions, System Integration
Testing and its validation against ER/ Particular Specification (PS). The final deliverable is the generation of the
Final V&V Report for the Railway as a whole.
In this paper, the authors, being involved in the requirement management works for a recent mega size metro
project in South East Asia, will share their experience on the set up of a Requirements Management Framework
including the challenges encountered during its implementation, the pragmatic approach adopted to manage
expectations and highlights on the lessons learnt. The paper uses the safety critical system, Signalling System
Contract, as an example to illustrate how challenges are tackled in this process leading to the production of the
Final V&V Report in time for the successful opening of the railway.
1 INTRODUCTION
Systems Engineering is playing an ever important role nowadays where more complex multi-disciplinary systems
are being built. This is reflected in the recently updated ISO/IEC 15288 System Engineering Standard (2015) since
its first issue in 2002. Systems Engineering is an interdisciplinary approach for the realisation of successful
systems, in our case, a Railway which is composed of multidisciplinary sub-systems, orchestrated in a complex,
structured and organised manner.
Requirements Management is the branch of Systems Engineering which addresses the process of identifying and
monitoring the stakeholders’ needs (we called it Employer’s Requirements in this Paper) and the systems
functionalities. The objective of Requirements Management, with the use of computerised tool, is to incrementally
evaluate the accuracy and sufficiency of the system solution proposed, by tracking its progress from design phase
to system testing and delivery stage.
For Railway Systems Contract, a chapter in the Specifications for Verification and Validation Requirements is
commonly found, coupled with submissions of V&V Plan, V&V audits, V&V reports for Design Phase and Testing
Phase to achieve incremental monitoring of compliance and possible corrections and adjustments at an earliest
possible stage of the project. In particular, for safety related systems, this is of significant importance for systems
at Safety Integrity Level (SIL) 2 or above. The V&V process is illustrated in Figure1 below:

Figure 1: V-model of Project Life Cycle Diagram

Verification and Validation Process of a recent mega size Metro Project Page 1 of 8
This ultimate goal is to confirm the Employer Requirements (ER) are fully verified & validated through the Systems
Specifications (Particular Specification – PS, General Specification – GS and Interface Specification – IS) and the
Testing Reports at the Final Testing and Commissioning Stage. There are other benefits achieved through the
systematic life cycle management, such as life cycle cost reduction.
2 SYSTEM ENGINEERING MANAGEMENT PLAN
2.1 Overview
The process of managing and controlling technical requirements of the Project is defined in the System Engineering
Management Plan (SEMP). The SEMP describes in detail, the tools used during different stages of the project
development in order to verify and validate that requirements of the project have been incorporated into the design
and are evident through the testing and commissioning activities.
Adopting the “V” Curve approach helps to ensure that the requirements which are identified, decomposed,
apportioned to the appropriate Sub/System are traceable through the entire project lifecycle and verified and/or
validated as appropriate. Once a requirement is decomposed, it is assigned to one or more of the following
categories:
• Functional; Performance; RAM; Safety; Design; and Other (Non-technical, procedural or standards)
Assigning a requirement to a particular category, facilitates linkages, traceability, subsequent manipulation and
management.
The functional relationships of the Contract Documents are depicted below. Functional clauses (System
Requirement Specification - SRS) are the breakdown of the ER which maps into different Specification Clauses of
various Work Package Contractors (WPCs).
The functional relationships of the Contract Documents are depicted below. Functional clauses (SRS) are the
breakdown of the ER which maps into various clauses and sub-clauses of Specifications for different Contracts.
Each contract is to be executed by a WPC selected through a tendering process.
It is worth noting that all ER clauses were mapped into PS Clause(s) of one or more WPCs and no gap is expected
to be identified.

Figure 2: Relationship between Contract Documents

Verification and Validation Process of a recent mega size Metro Project Page 2 of 8
2.2 Requirement Management Tool
The tool adopted to track and link the requirements for this project is the IBM Rational DOORS (Dynamic Object
Oriented Requirements System). It is used to demonstrate all identified requirements originating from the
Employer’s Requirements, have been properly verified and validated through all System Packages. Any gap and/or
mismatch in the requirements can then be easily identified with this computer based tool and be mitigated at an
early stage, e.g. Design or Factory Acceptance Test (FAT) stage.
DOORS is used for the following purposes:
• Store Project requirements documents;
• Maintain traceability between requirements and objective evidence;
• Store and manage interfaces;
• Support the change impact analysis.

Figure 3: DOORS Requirement Database Snapshot

2.3 V & V Activities
2.3.1 Overview
The main purpose of the V&V process in each stage of the Project is to achieve the following:
• To guarantee requirements consistency and traceability project-wide;
• To track and record project-wide requirement changes through-out the project life;
• To map requirements between Employer’s Requirements and Contract Specifications;
• To identify any gap and/or mismatch in the requirements project-wide;
• To provide total configuration management and change control facility;
• To facilitate impact analysis on requirement changes; and
• To demonstrate system compliance to requirements.

2.3.2 Requirement Capture Process

The Requirement Management process involves Requirement Capture, Requirement linking and Requirement
Updating sub-processes. The scope of each sub-process is given below:
• Requirement Capture : identifying a systematic approach in converting each clause / paragraph
stipulated in the ER and PS, into a SMART (Specific, Measurable,

Verification and Validation Process of a recent mega size Metro Project Page 3 of 8
 Achievable, Realistic, Testable) requirement item and store them in a
database repository which would allow easy retrieval and update
• Requirement Linking : each ER requirement item and each safeguard for every identified
hazard item is captured in the database and linked to the relevant
requirement item(s) in PS;
• Requirement Updating : Updating the database when requirements are changed or modified
due to various reasons. The affected requirement items in the PS’s are
needed to be updated and relinked in order to ensure its correctness
and validity

2.3.3 Requirement Database

All the Project Requirement clauses were stored in the DOORS database (Requirement Capture), which
subsequently linked to show its relationship between hierarchy levels (Requirement Linking). Update on the
Requirement clauses is required whenever there is an approved change (Requirement Updating) by the client.
The illustration of database architecture of DOORS is as shown below.

Figure 4: Database architecture of DOORS

The flexibility of the IBM Rational DOORS enables the requirement clauses modules to be exported and tabulated
to show the traceability compliance matrix from ER mapped to PS as shown in Figure 5 below. This can enhance
the submission to a client with a simpler demonstration of traceable compliance instead of showing the DOORS
database to the client.

Verification and Validation Process of a recent mega size Metro Project Page 4 of 8
 Figure 5: Traceability Compliance Matrix that mapped ER to PS
2.4 Gap Analysis
A Gap Analysis between ER and PS is conducted with an aim to identify any gap that may exist between the ER
and PS through the use of the established requirement management process and DOORS database. The detailed
steps of the assessment of the gaps identified in ER are listed as the following:
• Identify the gaps in ER
• Further assess on the identified gaps
• Update the Gap Analysis for ER based on the assessment result
• Propose way forward for the identified gaps in ER
Having gone through all the clauses in the ER, some requirements are found to be not captured in any Contractors’
PS. Further study of the ER is then carried out through discussion with the client’s representative and support from
the Contractors as well. The outcome of the assessment is used to update the traceability of ER to the relevant
Contractors’ PS. At the end of the Gap Analysis process, it concluded that all the approved changes to the PS has
been completed and all the identified gaps have been closed.
2.5 Change Control
Requirements under management within the DOORS database need to be maintained current throughout the
project lifecycle. To ensure that requirements remain current, any changes that cause direct impacts or affects the
lower level requirements indirectly is needed to be identified.
In accordance with the Project’s change control procedure, all changes to the WPCs’ PS must be reviewed and
approved. It is a mandatory requirement to conduct an individual impact analysis on each and every proposed
change to support the approval process. For each identified change, the impact analysis assesses the effect, if
any, on the requirement and to any lower-level requirements linked to it. An impact analysis report is prepared to
analyse the impact of changes to the requirements with the help of the DOORS database. In the event that an
impact is identified, the requirement linkages within the DOORS database are revised to match the change. In
parallel, the documents within which the requirement resides are updated accordingly.
2.6 Final System Integrated Test (SIT) and its traceability
The purpose of the Final-SIT is to demonstrate the critical integrated functions such as Radio Communication,
Power Trip, Train/PSD Synchronisation, OCC/BCC Switchover and Station Open/Closed Operation Functions are
properly implemented under normal, degraded and emergency modes of operation. It is defined as the final tests
to be undertaken to ensure overall compatibility of the performance among all interfacing systems to confirm the
readiness of the overall system for Trial Operations to commence.
A V&V review was also conducted for the mapping between ER clauses and the Final-SIT Test Procedures. This
supplements and reinforces the compliance of the ER requirements on critical integrated functionalities.

Verification and Validation Process of a recent mega size Metro Project Page 5 of 8
2.7 V&V Audit and Assessment
A V&V Audit and Assessment Workshop is performed regularly to ensure that requirements are properly managed
by the WPCs. The outcome of each assessment is recorded in a formal assessment report that is issued to the
assessed party. Due to project time constraints the audits are initially carried out on a requirement sampling basis
and subject to the outcome of the initial audit a decision can be made of how much further depth is required. The
objective of the requirements assessments is to assess, for example,
• If a robust requirements management approach has been implemented
• If requirements have been properly identified
• If requirements have been properly broken down
• The creation of SMART requirements
• If the requirement is correctly classified
• That the requirement attributes are correctly assigned
• That the V&V method is assigned
• That child requirements provide a complete satisfaction argument
• The correct selection of child requirements
Adjustment on the WPC’s requirement management approach may be required subject to the assessment findings.
2.8 Contractor V&V Process
Like many other Railway Projects, Contractors’ V&V submissions were required to be submitted at Final Design,
FAT and Final Test stages, governed by a V&V Plan with suitable audits as deemed required. Pre-defined
templates for reporting were distributed during the assessment / audit workshops arranged to facilitate complete
and quality deliverable be prepared by the WPC for submission. Summary data that facilitate the V&V analysis and
cross checking to identify early problems is produced and regularly updated.
Examples of the summary table showing the various attributes of requirements at different stages of the Project
are given below:
V&V Functional Performance Safety Non-Technical RAM Uncategorized Total Total
Phase Requirements Completed
Completed Total Completed Total Completed Total Completed Total Completed Total Completed Total
Design 959 959 453 453 130 130 153 153 27 27 62 62 1784 1784
FAT 606 606 178 178 34 34 36 36 2 2 34 34 890 890
PICO 50 50 4 4 6 6 3 3 2 2 1 1 66 66
PAT 552 552 228 228 14 14 33 33 3 3 23 23 853 853
SAT 299 299 186 186 15 15 7 7 0 0 6 6 513 513
SIT 23 23 16 16 3 3 9 9 0 0 2 2 53 53
Total 2489 2489 1065 1065 202 202 241 241 34 34 128 128 4159 4159

Table 1: Summary table showing the requirement attributes at different project stages
According to Table 1, the mapping is not necessary one-to-one for each verification and validation stage which
means that one requirement may be validated at multiple stages.
2.8.1 Signalling
Signalling Contractor is one of the most disciplined system contractors due to its high safety related / safety critical
classification and certification requirements. Nonetheless, their internal V&V system may be perfect in its own right
and may not necessarily follow what was generally specified in the Contract. The requirement structure that is
adopted by the Signalling contractor is shown below.

Verification and Validation Process of a recent mega size Metro Project Page 6 of 8
 Figure 6: Typical Requirement Structure from Signalling contractor
As illustrated in Figure 6, the highest level (Level 1) requirement for the contractor is the Customer Specification,
the starting point of the system design and development. A Customer Specification requirement will be satisfied
by a lower level (Level 2) System Requirement Specification, which then will be linked to a Level 3 requirement
(Sub-system Requirement Specification) and so on, until the lowest level of the hierarchy which is the Test and
Verification evidences. It is worth noting that Level 0 (Employer Requirement) is usually not included in the
contractor’s scope on requirement management and hence it is not presented in their V&V submission.
The contractor classified the Customer Specification requirements into three different categories namely
Functional, Technical and Non-Functional. Each of these categories will be validated through testing of the
Sub/System test modules and or verified through Sub/System verification modules through audit and analysis
verification. Similarly, the contractor is required to go through a V&V process to cover the whole Project Life Cycle
(Design, Manufacture, Installation, Testing and Commissioning Phases) to demonstrate the verification and
validation of the Customer Specification requirements is satisfactorily performed.
In the final site testing stage of Initial Phase Operation, all Functional and Technical requirements were linked to
the lower level for traceability and eventually linked to the Test and Verification evidences for the Sub/System level.
The summary statistic of the Customer Specification requirements is shown below.
Outstanding
Planned Linked Completed Linked
PS Requirements Requirements for
Requirements Requirements
Linking
Functional 858 858 0
Technical 355 355 0
Non-Functional 838 520 318
Total 2051 1733 318
Table 2: Summary status of linkages at final stage
Missing links for Non-Functional requirements were identified in the PS which related to System Assurance, HSE,
QA and process. Extra effort was normally required to conduct V&V assessment in Contractor Design Office with
numerous follow up discussions in order to resolve all the queries and missing links shown in their V&V Report.

Verification and Validation Process of a recent mega size Metro Project Page 7 of 8
2.9 Major Challenges and Solutions
Throughout the project lifecycle, there are many challenges faced by the Project Delivery Partner in the
Requirement Management process. Table 3 below summarises the challenges and the proposed solutions to be
considered for future projects.
Challenges Proposed Solutions
Only a few WPCs are using DOORS. The remaining
Using DOORS or a common requirement
Contractors are using excel spreadsheet as a
management tool.
requirement management tool.
No standard template is being used (no matter they Specify a common Traceability Matrix template in
are using DOORS or Excel spreadsheet) Contract.
V&V is usually considered as second priority for the
All Contractors to submit the V&V reports on time by
WPCs. Documentation/Paper works are pending for
imposing payment constraints.
test report submission.
Compliance is demonstrated in two steps. First by
linking the requirement to a test case/procedure. The
final step is to complete the site test and update the Validation is defined to be demonstrated through test
V&V submission. However the time window available report to complete V&V process.
for site testing is diminishing when Trial Operation is
approaching.
It is a matter of priority and subject to resources Support from Senior Management is very important
constraints. with sufficient resources.
Comparison between DOORS PS requirements and
A common set of requirements (deletion of non-
WPCs’ V&V submission can only be made after WPC
requirements) shall be defined and use by PDP and
has submitted their V&V report and hence it is often
Contractors.
too late to align the requirement entries.
Table 3: Challenges and Proposed Solutions

3 CONCLUSION
Vigorous V&V process was in place for the execution of this mega size. It was demonstrated that all the
requirements in the ER have been fully linked to the PS, with the linkages captured in DOORS Requirement
Management Database. System Integration Tests were performed to validate the critical interface functions defined
in the Specification. Full compliance of the Contractor’s work is subject to completion of testing to demonstrate all
the requirements are met. Lessons learnt were captured and summarised for consideration in future projects.

Verification and Validation Process of a recent mega size Metro Project Page 8 of 8
TEST, COMMISSIONING AND INTEGRATION
STRATEGY FOR IMPLEMENTATION OF CBTC
TECHNOLOGY ON A BROWNFIELD METRO SITE
Dr. Daniel Woodland, CEng, MEng (Hons), FIRSE, Ricardo Rail
Monish Sengupta, CEng, MSc, MRes, MIRSE, MInstP, Ricardo Rail

SUMMARY
A robust ‘Test, Commissioning and Integration Strategy’ is vital for a brownfield Metro site looking to upgrade with
a CBTC solution. This paper reports on the outcome of research conducted by the authors and provides an outline
of the requirement and basic parameters for such a strategy. A few key points that will be highlighted within the
paper include:
• 67 identified risks for test, commissioning and integration activities;
• Explanation of the reasoning behind inclusion of these risks;
• The recommendation that Metro infrastructure managers develop both a Test, Commissioning &
Integration Strategy and more detailed plans elaborates on the approaches to be adopted, and in
particular address the 67 risks outlined in this paper;
• The recommendation that Metro infrastructure managers should require their suppliers to produce
detailed Test, Commissioning, Integration and migration plans for their scopes of supply, demonstrating
how they will comply with and contribute to fulfilment of the programme level and system level plans and
ensure the 67 risks are fully addressed.
1 INTRODUCTION
Communication Based Train Control (CBTC) is leading a new era for rail transit control: enhancing flexibility and
reducing maintenance costs. The fundamental goal of modern CBTC is to optimise the rail infrastructure use in
terms of safety and capacity.
Almost all of the metros around the world are heading for high capacity CBTC systems – and many are doing so
as brownfield sites. The intended outcomes of all of these metros are:
• Business Transition – moving service delivery to a more flexible, responsive & customer focussed model
• Increased Capacity
• Improved Reliability
• To enable higher levels of automation
• Improved customer experience
• Reduction in whole life costs
• Enhanced energy efficiency / reduced environmental impact
Usually the programme of implementation is characterised as “highly complex and seldom undertaken in the
Nation.” This makes programmes for brownfield upgrade relatively high risk (at least when compared to a new
build) and the application of system Integration techniques / practices all the more important to manage the risks
and complexity.
For such projects, carefully planned and co-ordinated Testing and Commissioning regimes will be key to the
successful introduction to service and integration of numerous complex subsystems each being integral to
achieving the overall successful upgrades.

Test, Commissioning and Integration Strategy Page 1 of 12

2 METHODOLOGY
In carrying out their research for this paper, the authors adopted the RSSB ‘Testing and trialling: Good practice
guide for testing and trialling new technology for Britain’s railways’ (published in May 2014). This document is fairly
high level in detail and broad in its coverage – such that not all elements are applicable to a Metro CBTC solution.
However, a high level review of the document identified the elements applicable to this scope and the authors then
used these as a check list to pull in the extensive experience of Ricardo Rail consultants, our clients and our partner
organisations on metro (and other rail) projects worldwide, much as a set of guidewords would be used in a Hazard
Identification. This acted as a prompt for thought and discussion that could be captured, along with the findings of
an extensive literature review, as a comprehensive set of risks and lessons learnt. It also provided a means of
ensuring that all pertinent aspects for planning of future Testing, Commissioning and Integration for a Metro railway
had been captured. The result of this exercise was a list of 67 risks to be addressed, accompanied by detailed
lessons learnt for each. This was further peer reviewed by both Ricardo experts worldwide and client
representatives.
Unfortunately, the limitations of word count and space mean we cannot fully report the findings in this paper, but
we have attempted to capture all 67 risks and provide some explanation as to why they are considered to be risks.
3 MAJOR SYSTEM INTEGRATION RISKS & LESSONS LEARNT
3.1 Why do we need to test?
There are a number of potential purposes for testing and it is important that the purpose behind any given test is
understood, such that it can be tailored to achieve the desired output. Purposes may include demonstrating:
• Railway characteristics needed for design (e.g. signal sighting and PTI issues);
• That the proposed or implemented design will meet the reliability, availability, maintainability, safety and
performance requirements;
• That components and sub-systems meet the detailed design specifications (including regression testing
where updates are required);
• That components and sub-systems produce correct outputs during extreme and failure conditions
(including environmental conditions);
• Correct installation to the application design;
• Safe and functional integration;
• Operability and operational readiness, including passenger interaction;
• Compliance with legislation, standards and the User Requirements;
• Physical and Cyber Security.
In addition, there may be a need for test facilities to enable replication of problems identified during field testing or
in service, in order to enable identification and testing of potential solutions.
Risk 1 Purpose of testing overall is not agreed at an early stage and some benefits of testing and
integration activity are therefore missed
Risk 2 Purpose of testing is restricted to limited aspects, leaving other relevant aspects untested

3.2 Types of Testing Activity

Modern systems are too complex to fully test using traditional methods post installation alone. In order to ensure
adequate testing coverage and cost effective integration activities as early as possible, a variety of testing
approaches are required throughout the ‘v-lifecycle’ as summarised in Figure 1.

Test, Commissioning and Integration Strategy Page 2 of 12

 Figure 1: System Testing Model
In addition to these ‘project’ test elements, supplier(s) are also likely to carry out detailed product factory tests as
part of their generic development activity, rather than specifically as part of a particular project. Results from this
testing may be used as evidence towards compliance with project, legal and standards requirements.
The extent of testing should be based on criticality of functions with all safety functions intensively tested, whilst
testing of non-safety function should be optimised to avoid unnecessarily delays to revenue service operation. It
should be noted that ‘testing’ in the broadest context includes inspection of documents to ensure adequate
assurance of safe systems and processes, factory based inspection of components and systems to ensure quality
control, as well as site based inspection to ensure correct installation and that installed equipment has not been
damaged during transit / installation. Audits and inspections (including. test witnessing) should be carried out
throughout the entire development process as part of quality checking.
There may also be significant benefit obtained through early trials of system elements on the railway infrastructure
- for example, early deployment of elements such as point machines and balises for trials / to confirm that they
perform as expected in environment before full roll out.
Risk 3 System Proving and integration testing is left until a stage where costs of rectifying identified
issues are higher than could have been achieved
Risk 4 System Proving and integration testing is left until a stage where programme could be delayed
whilst issues are rectified.
Risk 5 System Proving and integration testing is inadequate / left until a stage where poor performance
/ reliability affect services
Risk 6 System Proving and integration testing of non-vital functions is excessive, resulting in undue
delays to programme or impact on operating services
Risk 7 A one size fits all approach to testing, commissioning and integration may not enable most
efficient and effective approaches for all asset types
Risk 8 Legacy system reliability data is not available or understood, causing reliability analysis to take
longer than planned to be completed

Test, Commissioning and Integration Strategy Page 3 of 12

3.3 Standards
All stake holders need to agree the standard that apply to a particular scope of work and how compliance will be
demonstrated - including testing evidence required, how that shall be obtained, by whom and where.
Standards, including company, national and international standards may:
• Include ambiguities or gaps in coverage
• Be written around older technology / processes
• Change (be updated, superseded or added to) during the life of the project
• Require some interpretation / clarification for application to modern systems and may also necessitate
derogation or unfavourable product development to satisfy the standards requirements. Inflexible
application of legacy standards to new technologies can result in substantial delays to system
development and sub-optimal system performance (as the product no longer works as originally
envisaged).
Risk 9 Not all applicable standards are identified in the contract or in system development,
necessitating re-work before compliance can be demonstrated and acceptance obtained
Risk 10 Applicable contract standards change during the programme, necessitating re-work before
compliance can be demonstrated
Risk 11 Applicable contract standards do not comprehensively address the requirements for new
technology leaving ambiguity over requirements. This could necessitate re-work before
suitability can be demonstrated and product acceptance can be achieved
Risk 12 Applicable contract standards impose requirements that are inappropriate for new technology,
necessitating concessions work before Test, Commissioning and Integration activities can be
completed and compliance can be demonstrated
Risk 13 Applicable contract standards impose requirements that are inappropriate for new technology
but concessions are not granted. Solution re-design may be required before compliance can
be demonstrated
Risk 14 Concessions and / or Regulatory Approvals may be required for some on-railway tests, with
potential for delays to programme if these are not identified and agreed early enough

3.4 Integration activities

At a basic level Integration means fitting parts together to make a whole, including their physical and functional
interaction. It is important to consider the full system – so station systems, Platform Edge Doors, etc. need to be
considered as well as CBTC and Rolling Stock. It is also important to remember that integration is not simply a
matter of getting technical systems to work together, but also includes overall system operation and integration of
Human operators and users into the system. The complexity of what end users are being asked to do and the
criticality of their actions must be understood early and designed into the solution.
A clear operational concept, system architecture and system interface definitions are needed early on in the
programme, with clear contractual requirements and agreements to define which party should take responsibility
for resolving a safety or performance requirement.
As part of integration activities, the operating & maintenance organisations must be involved in elements such as:
• The hazard analysis and risk assessment process, to ensure all their risks are controlled during testing.
• Identification and acceptance of control measures or contributions to them, where it is proposed for
mitigation of hazards to be implemented procedurally rather than through system design – including
additional requirements placed on the operator by any migration configuration.
Minimisation of mode change boundaries (occurrences, how often they will be encountered by a driver and how
long they will exist) should be sought in the system design and migration plans. Where mode changes cannot be

Test, Commissioning and Integration Strategy Page 4 of 12

avoided, simplicity in the mode change technical design and operational requirements should be sought and it
must be recognised that constraints will be imposed by the technical safety solution at the boundaries which will
restrict throughput.
Risk 15 If it proves necessary to pass Safety Requirements or other constraints onto system operators
and maintainers in order to demonstrate safety or achieve operability, there is a risk that they
will not accept these
Risk 16 Mode change boundaries (temporary or permanent) carry inherent risks for technical /
operational reliability and safety, presenting additional complexity for integration & test activity
Risk 17 Scopes of supply, the philosophy of operation and interfaces between them are not identified
and agreed early on. System development and design activity within different scopes diverge
from each other and from operations planning. They will not then integrate / deliver the required
performance without major re-work, cost and programme delays
Risk 18 Scope of testing does not adequately cover actual usage when in service, resulting in safety
issues becoming evident in service
Risk 19 Scope of testing does not adequately cover actual usage when in service, resulting in
performance issues becoming evident in service

3.5 Physical versus virtual testing

In general, physical testing is only possible once equipment has been fully designed, manufactured and (depending
on the type of test) possibly installed. Virtual testing can be performed earlier in the programme, but there is a risk
that it will not accurately reflect physical implementation in terms of function, timing and performance. A
combination of virtual and physical testing is therefore to be recommended, enabling early virtual testing to prove
concepts, corroboration of virtual test parameters through early physical testing, validation of testing / operational
concepts through full physical test implementation on an integration test rig, a test track and ultimately on the
railway itself.
Risk 20 Physical tests are only possible once equipment has been fully designed, manufactured and
possibly installed. Issues identified at that stage may require expensive re-work and cause
programme delays or result in sub-optimal performance in operation
Risk 21 Virtual Tests do not accurately reflect physical implementation, resulting in late identification of
issues and expensive re-work or sub-optimal performance in operation

3.6 Where can we test?

In order to maximise efficiency of testing and integration activities, whilst minimising demands on resources and
disruption to the operational railway, a hierarchy of test approaches can be considered as desirable:
1) Factory base integration rig:
• Testing of every function/sub-function; all internal and external interfaces, messages and commands
(with real equipment wherever possible and simulating a realistic range of data communications
message latencies and internal/external equipment response times where not);
• Running a range of operating scenarios consistent with anticipated operating procedures;
• Simulating a range of failure scenarios and replicating issues encountered during field testing to
investigate issues and solutions;
• Stress testing to see how the system performs when traffic (whether trains or data flows) is at
maximum loading (or even higher than anticipated), such that any issues are identified and can be
resolved before they become apparent in service;
2) Off-Railway test track:

Test, Commissioning and Integration Strategy Page 5 of 12

 • Confirming vehicle interfaces/characteristics (including multi-vehicle trains), wayside
interfaces/characteristics (e.g., interfaces to external equipment such as interlockings and platform
edge doors) and vehicle/wayside data communication links.
• Dry-run tests to be performed on the actual railway
• Test cut-over between existing and new systems
3) Shadow running;
4) On-railway in engineering hours’;
5) On-railway in extended engineering hours;
6) On-railway in line closure.
Only a few parts cannot be fully tested in the 'factory' (some aspects of the interface between rolling stock and
signalling; radio coverage; the database of field data; functions for management of large numbers of trains; correct
and undamaged installation (see section 9 of IEEE 1474.4: 2011 and EN62267:2009 for guidance on this).
There will be practical limits as the extent to which a test track is representative of the actual railway operating
environment, and as a consequence, many of the test track tests will need to be repeated in the field. However,
the goal should be to minimise the field test requirements and to ensure that prior factory and test track testing
maximise the probability of success of any required field testing.
Risk 22 Testing on the railway itself results in excessive passenger disruption through line closures.
Risk 23 Test facilities are not sufficiently representative of the real railway and/or full system
implementation to enable detection of all performance issues, resulting in late identification of
issues and expensive re-work or sub-optimal performance in operation
Risk 24 Combining test facilities to achieve different objectives (such as integration testing and rolling
stock soak testing) creates potential for conflicts between those objectives causing one or other
form of testing to be delayed
Risk 25 Segregation of test facilities that aim to achieve different objectives (such as integration testing
and rolling stock soak testing) may result in increased costs and programme delays due to the
need to replicate facilities and provide access to additional equipment
Risk 26 Delays in testing due to unavailability of test, monitoring or faulting staff may impact the
implementation programme
Risk 27 Limitations in testing due to unavailability of client staff on location may mean that it does not
adequately cover actual usage when in service, and/or that opportunities for operational and
maintenance staff to identify and resolve issues early are missed, resulting in safety or
operability issues becoming evident in service
Risk 28 Limited client staff access to test and integration facilities may lead to lost opportunities for
operational, maintenance and acceptance staff engagement and buy in to the system
Risk 29 Security of test facilities is not adequately managed leading to unintended configuration
changes that invalidate test results
Risk 30 Test facility provider’s insurance may not be valid for trialling of new technology

3.7 Migration and Programme

Migration, and the programme of works to deliver it, may create or mitigate issues for testing and integration activity:
• There may be benefits (for cost and programme, as well as the risk associated with change) to minimise
the need for legacy system modifications during migration (e.g. signal sighting, train detection
boundaries, OPO information, stop locations, etc.).

Test, Commissioning and Integration Strategy Page 6 of 12

 • Substantial train modification and sub-optimal implementation (space / location of equipment; EMC;
interfaces and train lines / connections) are to be expected if the train is specified in advance of selecting
a CBTC supplier. It is generally seen as good practice to buy a train with CBTC fitment at factory - which
requires CBTC procurement in advance of rolling stock procurement.
• Condensed timelines may make it difficult to obtain required test conditions.
• Where testing is broken down into too small time slots it is often not possible to complete activities without
overrunning the slot. The potential for overruns can be exacerbated by attempting to implement too large
a block of change (whether that be in terms of area or technology change) in one go.
• There is a need for contingency plans for doing more / less if time runs away, and for alternate tests that
can be performed in absence of key test equipment, such that the most can be made of testing
opportunities without resulting overruns or loss of opportunity.
Risk 31 Testing on the railway itself with inadequate allowance for time required results in excessive
passenger disruption through possession overruns and safety implications through knock on
delays and overcrowding
Risk 32 Migration does not account for the modifications required to legacy systems in order to enable
on-going integration, resulting in extensive enabling works being required, and perhaps
identified late
Risk 33 Substantial train modification may be required if the train is specified / designed before the
CBTC solution is selected and specified {Note: The impact of this risk is higher and more likely
to materialise if old legacy stock is to be retrofitted}

3.8 Co-ordination of project work, operations and maintenance

Where a railway is being upgraded (a brown field site project), project related work must integrate with live railway
operations and operations and maintenance staff need to be ready for the changes being made to the railway.
Challenging and complex works planning activity will be required to enable efficient access and availability of both
testing / integration staff and the equipment that they require (test equipment, engineering trains, etc.).
Arrangements for construction and testing during trial operations must ensure that:
• Construction activities are kept separate from test activities and trial operations;
• A method is in place to co-ordinate the movements of both engineering trains and trial operations trains
to avoid conflict;
• Physical barriers exist to prevent encroachment between test areas and live operations;
• Measures are in place to protect track workers from test train movements;
• Clearly defined access booking process are followed correctly and in good time to avoid access to site
being declined;
• Equipment and systems needed for testing (e.g. test trains, rather than the system under test) is available
and in proper working condition, such that test can be completed and produce valid results.
Project activities must further ensure that operations and maintenance staff are engaged in the system
development and implementation, including:
• Involvement in the hazard analysis and risk assessment process for integrated testing, to ensure all of
the risks are controlled;
• Identification and accepted of responsibilities for control measures, or contributions to them;
• An operational readiness programme and related tasks (e.g. Training Needs Analysis, Training and
competence of staff), including a significant level of change associated with updating the safety
management system and preparation of Operation & Maintenance manuals;

Test, Commissioning and Integration Strategy Page 7 of 12

 • Integration of installation and testing with the maintenance schedule for the existing transportation system
for the duration of the field activities, so as not to prevent adequate maintenance from occurring;
Additional approvals and / or procedures may be needed for operation of a test train, particularly if the test requires
that it is not under control of the normal signalling system in operation for services on the line, or may cause that
system to operate incorrectly. Measures should be taken to ensure that no unintended consequences occur during
testing (e.g. signals, track circuits, points etc. affected in unexpected ways that may impact on legacy system).
There is potential, for example, for axle counter resets to be needed due to testing activity, or for failures to be
introduced into other legacy systems due to the different characteristics of test trains, etc.
Risk 34 Testing on the railway itself results in cancellation of legacy system maintenance activity,
resulting in poor availability and thus passenger disruption
Risk 35 Testing activity affects legacy systems in unexpected ways, causing disruption to their operation
Risk 36 Test trains are run in an area undergoing construction or maintenance activities, with
consequential risk to the safety of train and construction / maintenance crews
Risk 37 Poor co-ordination between projects (both under the same programme and other programmes
under the same, or different, Infrastructure Managers), including programme slippage and
delays

3.9 Test readiness

Test readiness depends on a number of diverse factors including planning activities and system readiness.
Specific areas to consider include:
• Specialist tools / equipment may be required for testing - and the testing will not be able to proceed if they
are not yet ready or are not available for use.
• Requirements for calibration of test equipment should be recorded in the test specification and checked
as part of the readiness to test.
• There needs to be checks on whether the assets are ready and testing has been properly planned for
trials / introduction.
• The methodology for testing may differ between Legacy systems and new CBTC systems (which may
require new / novel test approaches and procedures).
• Where systems are rolled out in regions / sections, the maturity of each one needs to be monitored and
targets confirmed achieved before moving on to commission the next session;
Testing for reliability is often not as effective as hoped and does not yield reliable performance on the actual railway.
Reliability data for both legacy and new systems is required as input for effective reliability analysis, which could
take more time than planned to complete if this data is not available when it is started.
Risk 38 Inability to utilise booked installation or testing slots on the railway results in additional slots
being needed and unnecessary disruption to services and / or maintenance activity
Risk 39 Inability to utilise test track due to testing time limitations, unavailability of test equipment or
failure of test equipment results in extended testing time requirement and delays to
programme
Risk 40 Testing activity is undertaken in advance of system readiness, resulting in inefficient testing
activity, incomplete results and failure to identify issues fully until a later stage
Risk 41 Specialist tools and equipment required are not available, delaying testing and impacting
programme
Risk 42 Insufficient time allowed for preparation of testing activities, resulting in inefficient use of
railway access, increased disruption to the railway and delays to programme

Test, Commissioning and Integration Strategy Page 8 of 12

 Risk 43 Products / systems are not matured / stabilised before proceeding with commissioning of the
first or next section, leading to issues and disruption on the railway
Risk 44 Testing cannot be completed or test results declared invalid due to test equipment being out
of calibration

3.10 Test plans and Resource allocation

The quality of system design documentation available will impact the quality of test plans. There is potential for
difficulty obtaining a complete and consistent picture from documents provided by different suppliers to inhibit
development of comprehensive and accurate test plans. Test Plans need to be clear and comprehensive and
careful consideration needs to be given to the level of resource that will be both needed and available, and to the
attributes needed for those resources:
• An engineering test plan should define the sequence in which components and sub-systems are to be
integrated, commissioned and tested; what test equipment and/or data is required for each individual
stage; what tests are to be performed / their pass criteria; who will do what; competence requirements
and how it is known that the assigned resources satisfy those requirements;
• It is important to only permit testing activity that has been reviewed, determined to be appropriate and
authorised to be carried out. It is a good idea to keep the permission process as simple as possible - and
to rigorously enforce its implementation.
• As a gap often develops between testers and designers it is important that full document control and
configuration management are applied. Test Plans need to be specific about configuration of the
equipment to be tested, including such things as Data and Software versions and the version of each
system interface. The tester should then be asked to confirm that the systems are to the correct
configuration before testing commences.
• Test readiness will require training of testing staff in both legacy and new systems;
• In the modern railway industry, it can be difficult to know whether individuals may have a conflict of
interest. This should be managed as part of the formal competence management system.
• Time is not just an issue for testing activity (preparation, testing and review), but also for wider integration
with operations and maintenance. The introduction of new and novel technologies and operating
practices (such as CBTC) represents a culture change for operations and maintenance, with different
resources / skills sets required. Existing staff will need to be re-trained - and during migration it will be
necessary to keep their training / competence up on both old and new systems, and all of the combinations
encountered on-route. This may require not just initial training but refresher training if implementation is
delayed.
Risk 45 Poor quality, inconsistent or incomplete documentation may result in poor quality Test Plans
and the potential for unexpected safety or availability issues to arise in service due to
inadequate testing
Risk 46 If it is not clear who should be doing what, parts of the test plan may be missed, resulting in
inadequate or incomplete test results
Risk 47 Authority to carry out work on the railway (installation, Test and Commissioning) is bypassed,
resulting in work being inappropriately carried out
Risk 48 Loss of version control for hardware / data / software implementations could result in safety
and availability issues arising on the railway as systems behave differently to expectation and
/ or have not been fully tested
Risk 49 If the sequence in which components and sub-systems are to be integrated and commissioned
is not understood and replicated in test plans, there is potential for unexpected safety or
availability issues to arise in service due to configurations not having been adequately tested

Test, Commissioning and Integration Strategy Page 9 of 12

 Risk 50 If it is not clear who should be doing what, parts of the test plan may be carried out by
resources with inappropriate competence levels, resulting in inadequate test results
Risk 51 That there is inadequate training and relevant experience relating to new technologies,
systems and the practices required to utilise and test them to underpin the competence of
Testing, maintenance and operating staff
Risk 52 That there is inadequate availability of staff with competence in legacy technologies, systems
and the practices required to modify and test them, to underpin the Design and Testing of
migration arrangements
Risk 53 Availability of operations and maintenance staff for training and other operational readiness
activities delays readiness for commissioning
Risk 54 If the competence of test, commissioning and integration resources is not managed, parts of
the test plan may be carried out by resources with inappropriate competence levels, resulting
in inadequate test results.
Risk 55 If staff are incentivised to pass tests that should have been failed, then inadequate test results
may be accepted and products / systems enter service on the railway without appropriate
proving

3.11 Stakeholders
There are many groups of stakeholders who need to be considered, including (but not restricted to):
• The Infrastructure Manager / Client organisation, including: Senior Management; Strategy & Planning;
Operations (Drivers / Service Controllers / Station Staff); Maintenance; Discipline Areas (Signalling,
Rolling Stock, Power, etc.)
• Any other affected infrastructure managers / operators;
• Supplier stakeholders;
• Unions;
• Passengers groups / community involvement;
• Emergency services;
• Heritage Groups.
Even within a single upgrade programme, different stakeholders (including different organisations within each
company and different companies within the supply chain) will have different interests and objectives.
Once stakeholders and their requirements have been identified, it is important to:
• Agree procedure for acceptance of tests on completion;
• Agree criteria for test acceptance (e.g. Pass / Fail criteria);
• Agree which party should take responsibility for resolving a safety or performance requirement identified
(e.g. one supplier, a second supplier or the operator?)
Risk 56 Potential for contractual deadlock over whether requirements have been met or not, leading
to programme delays
Risk 57 Stakeholders are not fully identified or consulted, resulting in hidden expectations becoming
apparent at a late stage causing delays & additional costs for re-work to address.

3.12 Admissibility of Prior Test Results

Many items of equipment, and even whole sub-systems, may have been previously used elsewhere and test data
obtained in preparation for commissioning those previous implementations, and in operation since commissioning,

Test, Commissioning and Integration Strategy Page 10 of 12

may provide a useful source of evidence in support of compliance and readiness assessment. However, there are
many factors that may impact how representative such results are for a different railway: For example:
• The prevailing environment / weather;
• Physical features of the network that change the expected performance: cast iron tunnels and track
construction (including the arrangement of reinforcing metalwork) can have significant effects on
communication media; the use of a different traction supply arrangement may change the earthing and
conductive path properties of the track arrangement; etc.
• If the same equipment is being used in a comparable environment but carrying out a different function or
being used in a different way (e.g. using previous experience / test results for an 'interlocking' when it
was being used as a level crossing controller).
It has become common practice in CBTC projects to accept environmental test results performed by the supplier
during their product testing or for another project, with differences between the equipment for the current project
being analysed very carefully during this process.
In the event of a not-quite-new product being adopted, there is also a risk associated with the use of software or
code from a previous application of the product to a similar (but not exactly equivalent) situation, or from latent
functionality within the system whose effects do not get tested or demonstrated because their existence is not
acknowledged. It is, therefore, important to understand what systems and data are being re-used and to consider
applicability of prior test results and operational experience.
Besides the systems being implemented on the railway, re-use may extend to factory set up (including simulators,
and documentation, such as test procedures or safety analysis) and the validity of these for the new application
should also be considered.
Risk 58 Prior Test results or operational / maintenance experience are unnecessarily excluded from
consideration, resulting in higher level of test requirement and delays to programme (possibly
also to increased passenger disruption)
Risk 59 Prior Test results or operational / maintenance experience proposed as evidence of suitability
is not representative of the environment in which the system / sub-system will need to operate
Risk 60 Prior Test results or operational / maintenance experience proposed as evidence of suitability
is not representative of the usage / application proposed for the new system / sub-system

3.13 Clear recording and reporting of test data

The testing to be completed at each stage, its purpose and how results will be used needs to be captured in the
overall test methodology, including what level of certainty can be achieved for each element as part of that and
what further testing will be needed / when.
If the progress of testing and significance of test results are to be clearly understood, then clear recording and
reporting of test results is required. Time then needs to be allowed for review and analysis of the test results, such
that the significance of those results can be understood and if necessary further testing can be carried out.
Test reports should include a summary of the tested system (confirming the test configuration, including such
things as Data and Software versions and the version of each system interface), dates of tests, any open test items
and whether the tests met the requirements or not. The report should then go into details as to which requirements
have been met and their results, any deviations from the specification, etc.
There may be potential for lack of clarity to arise through the reporting mechanisms used by different organisations
not being the same or clearly understood by each other. Use of a shared on-line database is now common practice
to mitigate this risk.
Risk 61 Insufficient time allowed for review of testing activities, resulting in significance of results being
missed and potential for safety or performance / reliability impacts to affect services
Risk 62 Levels of maturity and uncertainty in test results are not captured, resulting in false confidence
in progress made

Test, Commissioning and Integration Strategy Page 11 of 12

 Risk 63 Lack of clarity in test reporting makes progress difficult to monitor with potential for programme
and / or service delays whilst tests are repeated unnecessarily. Programme may be delayed
whilst full evidence is collected before approvals can be gained for use.
Risk 64 Lack of clarity in test reporting makes progress, completeness and applicability of test results
difficult to monitor. The decision to enter service may be made before testing is adequately
complete, with potential for service affecting safety, performance or reliability impacts
Risk 65 If system, wayside and train logging is not available, both on-site and via remote access,
capture and analysis of test results will be restricted causing delays to the programme

3.14 Supplier’s quality control

The railway should audit their suppliers / sub-suppliers regularly to confirm that they are working to the agreed
processes to maintain high standards for safety and quality.
Risk 66 Insufficient robustness and consistency of controls over manufacturing undermine ability to
produce accepted products to specification with consistent reliability and performance -
resulting in products that do not meet the required specification entering service
Risk 67 Lack of quality and safety management systems in place to deliver a supplier's products or
services undermine ability to produce products that are traceable in the event of a product
recall - resulting in products that do not meet the required specification remaining in service

4 RECOMMENDATIONS AND CONCLUSIONS

Based on the output from our research, Ricardo Rail recommend that any infrastructure manager looking to
implement a brownfield CBTC upgrade:
1. Produce a high-level Testing, Commissioning and Integration Strategy;
2. Develop a more detailed Testing, Commissioning & Integration Plan, which elaborates on the
approaches to be adopted, and in particular addresses the 67 risks outlined in this paper;
3. Develop a suite of implementation plans in order to provide guidance on the preferred approaches
to be adopted by eventual suppliers in support of the test, commissioning and integration strategy.
These should cover migration, Reliability, Availability, Maintainability and Safety;
4. Following completion of this suite of Programme level plans and the appointment of suppliers,
require those suppliers to produce detailed Test, Commissioning, Integration and migration plans
for their scopes of supply, demonstrating how they will comply with and contribute to fulfilment of
the programme level plans. In time, this will then lead to development of detailed supplier
installation and test plans for individual activities / stages of work, which must be accepted by the
infrastructure manager in order to ensure consistency with the overall test plans and minimise any
potential impact on operations and maintenance.

Test, Commissioning and Integration Strategy Page 12 of 12

EGLINTON CROSSTOWN LIGHT RAPID TRANSIT
SIGNALLING – HYBRIDISATION TO THE CORE
Colin Alonzo Williams, CEng MEng MIMechE MAPM MINCOSE AMIRSE
SNC-Lavalin Rail and Transit UK

SUMMARY
Eglinton Crosstown is a Light Rail Transit (LRT) line in Toronto that will run along and beneath Eglinton Avenue
between Mount Dennis (Weston Road) and Kennedy Station. This 19 km corridor will include a 10 km underground
portion, between Keele Street and Laird Drive and a maintenance depot adjacent to Mt Dennis station.
This paper describes how an interface between the S&TCS and the City’s TMS will conceptually operate. This will
be in order to achieve the combined objectives of minimising the impact to road traffic users whilst achieving the
highest possible service reliability for the ECLRT.
Keywords: CBTC, Interface Management, High Capacity
1 INTRODUCTION
The purpose of this document is to lay out, conceptually, the proposed methodology and overall command strategy
for the semi-segregated guide way portion of the Eglinton Crosstown Light Rapid Transit (ECLRT) project. To
achieve this goal, the City of Toronto’s road Traffic Management System (TMS) and the ECLRT Signalling and
Train Control System (S&TCS) need to communicate on a local level to influence both the local road signal timings
and pass the knock on effect to the ECLRT.
At fifteen locations in the semi-exclusive portion of the Right of Way (RoW), see Error! Reference source not
found. below, the ECLRT alignment will cross city streets at grade. This fact has resulted to the Project Agreement
(PA) requiring that “Project Co shall develop and customize the necessary interfaces between Project Co System
Infrastructure and City’s traffic management system.”

Figure 1: ECLRT Intersections

For a fully optimised system, the TMS and S&TCS not only have to communicate but strategically plan ahead their
interactions in order to make best use of available TMS green signal phases in the east /west direction. This
requires an overarching interface strategy that spans beyond the core requirements of each respective system by
defining interface strategy requirements.
The scope of this document is to specify how an interface between the S&TCS and the City’s TMS will conceptually
operate. This will be in order to achieve the combined objectives of minimising the impact to road traffic users
whilst achieving the highest possible service reliability for the ECLRT.

Eglinton Crosstown Light Rapid Transit Signalling Page 1 of 12

2 BACKGROUND
2.1 The Eglinton Corsstown Light Rapid Transit
Eglinton Crosstown is a Light Rail Transit (LRT) line in Toronto that will run along and beneath Eglinton Avenue
between Mount Dennis and Kennedy Station. This 19 km corridor will include a 10 km underground portion,
between Keele Street and Laird Drive and a maintenance depot adjacent to Mt Dennis station.
There are fifteen underground stations including three interchange stations at Cedarvale Station, Eglinton Station
and Kennedy Station and two terminal stations at Mt. Dennis Station and Kennedy Station. The above ground
section, known as the semi exclusive right of way, runs between Laird Drive and Kennedy Station, there are 10
LRT at-grade stops and three underground stations in this section.

The Eglinton Crosstown Light Rapid Transit (ECLRT) system will be equipped with a modern CBTC system,
operated in the underground section in Grade of Automation Level 2 (GoA 2), in the depot they will be fully
autonomous in GoA 4. In the semi-exclusive RoW, ECLRT trains will be driven by a train operator. During normal
revenue operation the trains will be operated in ATP-M (GoA 1) mode in this portion of the alignment. In ATP-M
mode, the responsibility for train separation and over-speed protection resides within S&TCS. In the semi-exclusive
RoW the train operator is responsible for deciding whether or not to progress through a signalized intersection,
based on the current LRT signal aspect and indications on the Train Operator’s Display.
At fifteen locations in the semi-exclusive portion of the RoW, the ECLRT alignment will cross city streets at grade;
these crossings are on average every 400m. To fully integrate ECLRT services into the wider City of Toronto traffic
network, a strategy of traffic management needs to be developed in order to mitigate the potential impact of mixed
road utilisation. There are a significant number of road junctions between the eastern portal and Kennedy station
which is the furthest. The distances between junctions are such that there will be significant impact on high
frequency LRT operations unless properly managed.
3 OVERVIEW OF INTERFACING SYSTEMS
The following systems and sub systems form the basis of the interface for this concept document.
3.1 S&TCS
The S&TCS is a CBTC system comprised of the following sub-systems.
3.1.1 Automatic Train Supervision Subsystem
The ATS subsystem monitors and manages overall train operation both for the mainline and the Yard. It provides
system supervision including automatic routing (ARS), schedule keeping (TMS), data acquisition, reporting, and
provides the interface between the control operators and the S&TCS. The ATS equipment suite primarily consists
of a number of servers located in the Eglinton Maintenance Storage Facility (EMSF) and operator workstations
located in the OCC at Hillcrest. This subsystem shall support the interface to the Traffic Controllers.

Eglinton Crosstown Light Rapid Transit Signalling Page 2 of 12

3.1.2 The Region Automatic Train Control Subsystem
The Region Automatic Train Control Subsystem (RATC) principally comprises the RATP and the RATO. The RATP
subsystem is the core safety component of the wayside S&TCS equipment. This safety redundant equipment
integrates the limit of movement authority calculation with the interlocking functionality.
The RATP performs the following interlocking functionality:
• Route protection using approach locking, route locking, and over-switch locking
• Protection against opposing and conflicting moves and the reverse running of manual trains
The RATO provides for ATO functionality for the wayside control system. The RATO functions include:
• Routing – The Region ATO receives a route from central control (ATS) and provides the logic
• Station sign messaging
• Train performance – Drives the train
The ATS provides route requests to the RATO as per the schedule or manual operator commands. The RATP
reports route status and field device status to the ATS. To achieve fully bidirectional traffic, the ATS schedules new
bidirectional routes. The RATP ensures LRT are protected and the RATO executes the routes.
3.1.3 Vehicle Automatic Train Control Subsystem
Each vehicle will be equipped with a safety redundant VATC subsystem and peripherals. In addition to speed
sensors, the VATC employs Norming Point Readers to detect the norming transponders mounted along the guide
way. These are used to determine the precise train position, and support accurate Station/Stop stopping. Both the
speed sensors and Norming Point Readers are located under-car.
The S&TCS onboard VATC architecture will support both 2 and 3 vehicle consists. Each two vehicle consist will
be fitted with a pair of redundant VATCs, one VATC per vehicle, that are capable of automatic on-the-fly switchover.
In a 3 vehicle consist; the VATC in the middle car will be dormant. Failure of either a VATO or a VATP will result
in an automatic switchover to the redundant VATC.
A Mobile Data Radio unit (MDR) and associated antennas are used to wirelessly communicate with the RATCs.
The train-to-wayside communications antennae are located on the roof of the vehicle. High availability is achieved,
since a single VATC failure will not affect operation.
Either VATC can fully supervise and control train movement regardless of the operational state of its redundant
counterpart. The Train Operator’s Display (TOD), also referred to as the Driver Machine Interface, is located in the
train operator’s cab and displays critical operational data to the train operator.
3.2 City of Toronto Traffic Management System
The City’s Traffic Management System is comprised of centralized “head-end” traffic signal control system and
local road traffic signal controllers, hereinafter referred to as Traffic Controllers. The Traffic Controllers are
responsible for operating the signalized intersection. The City operates a series of signal timing plans that are
designed for traffic conditions during a time period. Vehicle and pedestrian detectors are used to request actuated
phases. The system uses a distributed system architecture, which includes the TransSuite central software and
field Traffic Controllers shown in Figure 2.

Figure 2: The City’s Traffic Signal Control System

Eglinton Crosstown Light Rapid Transit Signalling Page 3 of 12

4 TRAFFIC MANAGEMENT STRATEGY
When the ECLRT revenue operation commences along the semi-exclusive RoW in 2021, the City of Toronto will
remain the owner, including operation and maintenance, of all signalized intersections. TTC will be responsible for
train operation. Therefore, it is essential for all stakeholders in this interface to have a clear understanding of the
City’s latest policies and strategies, and the operational strategy.
4.1 Transit Signal Priority
Unconditional TSP is provided on transit routes and intersections selected by the TTC. TSP shall not shorten the
walk time to below the minimum pedestrian clearance time. Amber and all-red intervals must not be [Link]
installation requests shall be sent by the TTC to the relevant DTO for review. After review and approval, the DTO
shall advise ITSO of the TSP approval.
Where pedestrian complaints increase after the implementation of TSP, the DTO in consultation with TTC shall
review the intersection's operations to determine the causes, to quantify the pedestrian delays, and to develop
measures to reduce delays. Modifications to the priority algorithm or offset transition process may be considered
at the location. Decommissioning TSP would be a last resort. Unconditional TSP is not allowed under the Project
Agreement. TSP can be requested only if a LRT is late.
4.2 Interfacing S&TCS with Transit Signals
Figure 3 below illustrates a typical, albeit simplified crossing at a roadway intersection. Road traffic signals and
LRT signals are not shown for clarity. Train (T1) is stopped at a nearside platform ready to depart. Motor vehicles
are negotiating the intersection from their given lanes. Some vehicles are travelling straight through the
intersection, others are making left or right hand turns.
Roadway Crossing

Platform

Platform

T1

2/14/2016

Figure 3: A Typical Roadway Crossing Intersection

The Traffic Controller algorithms governing vehicular and pedestrian traffic movements through the intersection
are predicated upon the availability of a detailed ‘picture’ of the state of the intersection at any given time. This
picture is derived by employing various types of equipment such as motor vehicle detectors embedded in the
roadway at strategic locations in and around the intersection and pedestrian crossing push buttons. The inputs
from these devices are interpreted and used by the Traffic Controller to cyclically allocate vehicular and pedestrian
intersection access phases in an optimal manner in accordance with the City’s traffic signal phasing policies.
The Traffic Controller includes logic that allows for automobiles, pedestrians, bicyclists, and trains to “share” the
intersection regardless of how they wish to traverse the intersection. Each of these actions for each roadway lane
is associated with a time slice within the Traffic Controller’s clock with each time slice comprising the aspects that
a motorist would see while negotiating their movement through the intersection.
From the train’s perspective each intersection has an associated “clock” depicted in Figure 4 below. The ICxy
Green Window represents the non-TSP LRT signal green time. The Extended Green Window represents the
additional LRV Transit Signal green time that is available to the LRV whenever the Traffic Controller implements
“Green extension” TSP.
The Early Green Window represents the additional LRT signal green time that is available to the LRT whenever
the Traffic Controller implements “Red truncation” TSP. The time slice between the dotted lines in the figure below
represents the portion of time that is not allocated to LRT movement through the intersection. Pease note that the

Eglinton Crosstown Light Rapid Transit Signalling Page 4 of 12

time slices depicted in the figure are not to scale and that the cycle time of the clock is based in the City’s policies.
Although not expressly mandated, early green and green extensions in the PA are given indicatively as 16 and 30
seconds respectively.
ICxy
Green
Window

Early
Window

Extended
Window

Figure 4: Time Domain of the Traffic Controller

For access to the intersection, the train need only be concerned with the “Green time slice” that will be allocated
to it by the Traffic Controller. Consequently the primary thrust of the interface design effort will be to optimize a
train’s performance such that it arrives at an intersection at a point in time that allows it to continue through the
intersection with minimal impact to its performance.
4.3 Original Concept: Using TSP as required
TSP in the context of TTC operations works by either functioning as an early green or green extension to the
through running phase parallel to the transit phase. When a train arrives at a predetermined point on approach to
a given intersection the S&TCS shall transmit a “train approaching” message to the Traffic Controller. The point
in distance and time on a train’s approach to an intersection that will trigger the transmittal of this message shall
be determined solely by the S&TCS.
This requirement obviates the need for Traffic Controller to have any knowledge of the train’s location. From here,
the traffic controller can either use a green extension or reduction. Figure 5 below shows the changes to a typical
cycle. If the traffic signal chooses not to authorise TSP, then the signal shall remain restrictive.

Figure 5: Green Cycle Extension

Figure 6 depicts ATP-M train behaviour on the approach to an intersection. The onboard S&TCS vehicle controller
(VATC) constantly calculates the train’s braking curve, and projects it out in front of the train so that the train can
adjust its braking profile before encroaching upon any condition warranting a train slow-down or stoppage. If the
LRV Transit Signal is not clear for the train to proceed, the train driver will be provided with an ATP-enforced speed
profile that if followed will bring the train to stop prior to the intersection waiting until the LRV Transit Signal becomes
permissive.
Send TSP Request Point of No-Return

Train’s Braking Safety

Curve Margin Intersection
Distance to Point-of-No-Return
and
Time to Point-of-No-Return

Tx

Distance to Intersection
and
Time to Intersection

Figure 6: A Train’s Approach to an Intersection

Eglinton Crosstown Light Rapid Transit Signalling Page 5 of 12

Once the train arrives at the Point of No Return (PNR) it will commence braking if the Traffic Controller has not
provided a permissive LRV Transit Signal aspect. The PNR is the distance from the intersection at which point the
train must commence braking in order to stop before entering at the intersection by a safety margin. Should the
intersection’s Transit Signal transition to the permissive state while the train is slowing down, the driver will be
permitted to continue through the intersection under his vigilance without stopping in accordance with the target
speed indicated on the Train Operator’s Display.
The original concept, whilst it works in theory is limited by three key factors:
• TSP Denial
• TSP Recovery
• Conflicting LRT movements
Typically, as shown in Figure 5, full traffic signal phases tend to run on phases of upwards of 120s. For an evenly
balanced crossing, as some are that cross Eglington Avenue, Green phases will be split between parallel and
perpendicular routes. If pedestrian and turning phases are taken into account as well, LRT permissive phases
could make up less than 40% of the total permissive time. This means that effectively, even with TSP an ECLRT
service is more likely to receive a restrictive signal than a permissive one.
Coupled with the PNR concept, LRT wouldn’t be able to use all of the permissive phase thus reducing the actual
permissive phase from an LRT further. Figure 7 below shows a graphic demonstration of the useable time for LRT
to cross intersections.
ICxy
Green
Window

Early
Window

Extended
Window

Figure 7: LRT Useable Time

The second issue relates to recovery from TSP usage. With the TSP lengths as alluded to in the PA, if a full TSP
of 30s was granted, this would be an unrecoverable time within a normal Traffic Controller cycle. This would then
put the controller out of phase, requiring several subsequent cycles to return to phase, potentially affecting following
LRT.
The third and more complicated effect is the issue of TSP conflicts. Traffic signals on the ECLRT network couple
together the Eastbound and Westbound headways at every traffic intersection like a set of switches. If the TSP is
provided for the first LRT then unless the second can make it through the intersection safely the route has been
blocked until the next traffic cycle potentially injecting minutes of delay at each intersection. Figure 8 shows a
graphical representation of this effect for a given intersection.
Active TSP Granted

Train 1

Direction of Travel
Send TSP Request Point of No-Return

Green Phase Countdown

5 seconds

Train 2 Train’s Braking

Curve

Time to intersection TSP Denied

15 seconds

Direction of Travel
EoA

Figure 8: Headway Conflict

Eglinton Crosstown Light Rapid Transit Signalling Page 6 of 12

4.3.1 Original Concept Observations
Lessons learned from the assessment of the original concept for ECLRT operation:
• Green/Amber countdown is vital for operations
• Permissive phase timings can significantly impact ECLRT operations
• Permissive phases for LRT for some junctions may be less than 40%
• Relying on TSP exclusively without adjusting the timetable is problematic
• Variations in TMS phase length would be difficult for the S&TCS to reconcile
• Changes of service mode during the day are not accommodated
• The notional headway and green timings do not naturally line up
• TSP usage should be considered only as a last resort
• TSP lengths should be limited to recoverable in a single cycle
4.4 New Concept: Adjusted Timetable and TMS Phase Operation
Based on the lessons learned from the original concept, a new concept was developed. The new concept attempts
to address the limited green phase availability by aligning the timetable and green phases to limit TSP usage whilst
always providing permissive aspects on time to the LRT. The concept is defined as follows:
• Pair LRT headways together so that LRT always cross, where logically possible, at signalised
intersections to reduce the amount of contradictory moves
• Design the timetable and phase timings for TMS signals together in harmony so that TMS phases and
ECLRT run times coincide to give LRT permissive aspects when they are expected to arrive
• Reduce the length of TSP intervention so that it can be recovered in a single phase whilst also ensuring
that no alteration to TMS cycles, such as pedestrian moves or turn extensions, can put the TMS out of
phase
• Allow the S&TCS to control the shift to different service levels in line with the ECLRT service
requirements and change the TMS phase settings according
4.4.1 Crossing at Intersections
Figure 9 shows the notional headway compared to the green cycle times for the intersections. It is important to
note that green phases vary significantly from intersection to intersection based on the size and traffic density of
the roads crossing the ECLRT route. The phases shown in the diagram are the permissive and restrictive aspects
for the crossing roads. This means that LRT need to cross under the restrictive, red, aspects at these intersections.

Figure 9: Current green cycle interaction

Eglinton Crosstown Light Rapid Transit Signalling Page 7 of 12

As shown in Figure 9, the green cycles do not fall naturally on the existing traffic plans so significant changes would
be required to allow LRT to cross unhindered. Further difficultly is encountered due to where LRT cross. Some
cross just before or just after junctions, creating the need for a significantly larger LRT permissive phase then if
LRT crossed at the signalised intersection itself.
TSP plays an interesting role in understanding LRT crossing. If we take a 120 second cycle for example on an
equally split junction with turning phases, then each road will have 60 seconds or permissive aspects. Adding 2
seconds of all red after each signal phase, the total cycle length would be 128 seconds. The minimum time
available for a turning would be 6 seconds of all green followed by 3 seconds of amber totalling 9 seconds. This
means that theoretically there is a maximum of 51 permissive seconds of a 128 second cycle or 40%.
Fixed paired headways as opposed to dynamic headways offer distinct advantages for a system such as the
ECLRT. Because of the strong interaction between the eastbound and westbound services, any control scenario
which relies primarily on TSP will eventually decay into a chaotic regime of contradicting TSP requests, reducing
the efficiency and performance of the service.
Pairing the headways at signalised intersections is a way of counteracting this. The principle is to time the LRT so
that when LRT cross paths, from eastbound and westbound respectively, they cross a signalised intersection. The
aim of this is to use control of the intersection once to authorise the movements of both LRT as shown in Figure
10.

Direction of Travel
Train 1

15 second dwell and 5 second

seconds intersection

Train 2

Time to intersection
20 seconds

Direction of Travel

Figure 10: Paired Operation

The first part of the new concept therefore is to redesign the timetable so that LRT:
• Cross signalised intersections in pairs
• The S&TCS ensures the LRT are on time for a given intersection
• LRT see only proceed aspects when they arrive at intersection PNR
Note, this may require:
• Managed sectional run times
• Managed acceleration or braking
• Managed dwell times
4.4.2 Phase Timing and Timetable Alignment
Figure 9 shows that even if LRT are aligned to always cross intersections in pairs, with the current cycles, train
regulation will eventually fall out of sync with the timetable leading to increased TSP usage and delays to ECLRT
service. In order to address this specific failing and to reduce TSP utilisation, the timetable and intersection phase
cycles need to be designed in unison to ensure they are always in sync.
Since the LRT will now be timetable to cross intersections in pairs, aligning the timetable and phasing only needs
to focus on one crossing time per pair of LRT rather than individual east and west services. Aligning the timetable
and phases requires:
• Design of the ECLRT timetable and intersection timings to ensure LRT always see permissive aspects

Eglinton Crosstown Light Rapid Transit Signalling Page 8 of 12

 • May require running some service closer together or farther apart than the 3 minute average for
sections
• May require longer or shorter TMS timings phases
• May require some TSP to function
• Some performance to be kept back to maintain time
With the majority of intersection timings along ECLRT, there really are only 40 to 60 second blocks of usable green
phase per cycle. With the use of TSP, the S&TCS will be able to request a slightly longer window however this can
only mitigate so much delay. Tools such as leaving some performance in reserve will be able to aid this.
If a LRV is delayed to the extent that the TPS will not be effective at extending the window, the next effective point
for TPS will be by creating an early green window in the subsequent window. Once behind a window, it will be
difficult to catch back up due to the cyclical nature of the traffic signals. This delay would permeate the timetable
all the way to the end of that section, whether that be the turn back in the east or entering the ATO zone in the
west. The only potential way of catching up a trip once late would be skipping a stop.
It would take a train being 2 windows late, 4 minutes or so, to affect the next service on the 20 TPH cycle. A delay
of 6 minutes affects 2 services and so on. This is where intervention to skip stations would be necessary.
4.4.3 TSP Length, Phase Restrictions and Recoverability
The use of TSP will be crucial to giving the S&TCS system more leeway for LRT running up to 40s late. Beyond
this, TSP will be required on some junctions. TSP however, will need to be limited in its length in order to
accommodate the minimum cycle times for the other elements of the cycle. If it is not limited, then the amber
countdown, the fixed point in every phase, will be moved, causing misalignment to the core timetable/phase
alignment.

One of the key strategies to make this work is to limit changes to the phase cycle, especially unpredictable changes
that will have a knock on effect to future cycles. This means that facilities such as pedestrian walk cycles and
extended turn cycles that can be inserted into the phase cycle with the use of push buttons or detector loops have
to be restricted in length. These cycles are still to be incorporated; they will however be limited, especially when
recovering from TSP.

4.4.4 Time of day management

Under normal conditions, without LRT operations to contend with, a traffic controller has a number of preset phase
cycles that it transitions to throughout the day, to manage differing traffic conditions expected at different times.
Even with the inclusion of ECLRT, this traffic management is required to best optimise the use of the City of
Toronto’s roads.
ECLRT also has changes in service level throughout the operational day. Train service frequencies on the semi
segregated right of way vary significantly to accommodate expected ridership. In most cases, these shifts of trains
per hour are not multiples of each other meaning they will not be able to slot into the same phase sequence as
previously used.
Thus, in addition to the maximum throughput case:
• Operational timetables and associated phase sequencing shall be developed
• The TMS shall store the required phase sequences
• The S&TCS shall tell the TMS when to change to the next sequence
• Understanding of how long the shift takes will be required
This methodology may be required to facilitate:
• Non stop running
• Service recover

Eglinton Crosstown Light Rapid Transit Signalling Page 9 of 12

5 INTERFACE ARCHITECTURE
Figure 11 below shows the proposed TMS and S&TCS system architecture at a local level. At this level, the S&TCS
ARS wayside equipment interfaces directly to the wayside local controller through a yet to be determined
connection protocol and cable. This connection will allow bi-directional communication between the systems to
enable dynamic updating of the local controller.

Figure 11: S&TCS to TMS Interface Block Diagram

In the case of the S&TCS to TMS interface, the local controller will be used to manipulate the road traffic signals
in order to enforce the overall area logic, the S&TCS is simply an East/WEST phase to the controller. In order for
this interface to truly be efficient, both the S&TCS timetable and the TMS phase cycles need to be in sync so that
LRT only see proceed aspects when they need them. This may require changes to existing phase cycles making
them shorter or longer as required. The basic underlying rules from the City of Toronto for TMS operation shall not
be violated.
In the event of an override request from the emergency services, the traffic controller will best decide how to grant
the priority clearance. This will require an additional layer of logic to incorporate potential transit movements and
delays in communication. For example, a LRT might be on approach to a traffic crossing which would have been
comfortably within the normal green phase timing. If a perpendicular emergency request is placed, without
cognisance of LRT capabilities, changing the signal quickly may cause a situation where the LRT will exceed its
new movement authority as it cannot react or brake fast enough.
Lastly the local controller needs to protect the LRT in the intersection until it has cleared. LRT should clear
intersections under green or at worst amber protection under normal conditions however there may be a situation
where an LRT remains straddling or partially encroaching into the traffic intersection. Under these conditions the
traffic signals should not be allowed to transition to the next phase, even if this causes an extension beyond the
standard traffic sequence protocols until the LRT is proven clear.
The ARS function of the CBTC system sets the routes for LRT throughout the operational day. The route setting
function is responsible for requesting status of elements such as points and crossings across each section before
it issues the movement authority to the LRT via the VATC. As such, the ARS function is required to run LRT on a
timetable that fits into the available phase windows provided by the TMS.
To accurately manage the traffic lights and maintain phase sequences throughout the day, it would be preferable
for the ARS to manage the transition between different service levels by requesting the traffic controller to change
sequence as required. This means that changes in service level of the ECLRT are matched by appropriate changes
in traffic light sequence timings.
The complexity of the coupling between the eastbound and westbound service is such that without management
of the routes themselves, route setting preference in one direction rather than the other would cause significant
deterioration in the service provided. This means that the ARS must balance the eastbound and westbound service
by pairing LRT across signalised intersections. This requires the timetable to operate in timing blocks rather than

Eglinton Crosstown Light Rapid Transit Signalling Page 10 of 12

a full headway system. Whilst this limits the ultimate capacity available, it will provide a service with higher timetable
punctuality.
6 CONCEPT OF OPERATIONS
The Concept of Operations for the on street semi-segregated segment of the ECLRT is key to the overall delivery
of service performance and reliability of the entire route. The following operational scenarios outline the responses
envisaged from the strategy laid out previously in the document.
6.1 On Schedule Running
On schedule running requires the S&TCS to create routes that are used to drive the green cycle timing down the
entirety of the ECLRT semi segregated right of way section. The S&TCS will create enough routes to drive every
cycle for every light even though not all of these routes will be used by an LRT. Utilisation of the routes will vary by
time of day as ECLRT services ramps up and down with demand.
6.2 Single Late Train
A single late train, caused by any number of issues, such as an extended dwell time or blocked intersection can
be managed in a variety of ways. Depending on how much delay has been introduced into the service, the late
running LRT can impact a number of successive ECLRT routes in that direction.
If, for example, the ECLRT is at a service level whereby every other route is in operation, then delays will have the
following impacts:
• 1 route late
o LRT falls back into the next available slot
o LRT can catch back up with its intended route if there is a sufficient station skipping location
o Else, LRT remains late until the terminus or tunnel section
o No other LRT services affected
• 2 routes late
o LRT falls back two routes affecting the successive LRT
o Both LRT are now late
o The first LRT may skip stops if available to catch up a route
o The second LRT can skip stops after the first has successfully caught up a route
o If time is unable to be made up, both LRT remain late until the terminus or tunnel section
• 3 routes late
o Second LRT is late two routes as a result
o Third LRT is now one route late
• More than 3
o Successive lateness backs up the service
o May require further intervention such as early turn backs

1.1.1 Late Running Service

In the event that significant delays have affected the service in one direction or both, the aim of the S&TCS should
be to restore the service rather than the timetable. This can be achieved with the following techniques:
• Skipping stops
o The first available tool is to use skipping stops to recover the service
o This has limited recovery powers due to the location and rate this can occur
• Nonstop running
o The next tool is to use nonstop running
o This takes time to align the traffic lights accordingly
o Can alleviate significant blockages
• Early turn backs

Eglinton Crosstown Light Rapid Transit Signalling Page 11 of 12

 o In extreme circumstances, at some locations LRT can turn back to stop the service early
o Takes time to restore the service beyond the turn back point
o Limits capacity due to turn back capacity

7 SUMMARY
Utilising TSP alone to manage the routing of LRT significantly reduces the service reliability whilst increasing the
run time for the on street semi segregated section of the ECLRT. By introducing phasing and timetable
management to the traffic system utilising the S&TCS ARS function tying the timetable to present TMS phases,
LRT and traffic routing efficiency and reliability can be increased.
Phasing and timetable management relies heavily on the S&TCS timetable being generated to work with a present
TMS phase cycle. Triggering of TSP is kept to a minimum. Through careful management this methodology can be
used to always present LRT with permissive aspects.
7.1 Next Steps
The following are recommendations for additional work to verify these concepts are required:
• Modelling of the phasing and timetable management methodology is carried out
o This will require the creation of a draft timetable around the paired crossing at intersections
o Modelling of stop skipping locations;
o Modelling of nonstop running;
o Modelling of hybrid nonstop and stopping service running.
• Ensure that the Peek ATC 100 traffic controller:
o Can send an amber countdown;
o Can send out a green countdown;
o Change phase sequence upon external request;
o Can meet the needs of the ECLRT.
• Ensure that the Bombardier CityFlo 650 system can:
o Communicate securely and safely with traffic controllers;
o Achieve the routing requirements to allow efficient operations.

Eglinton Crosstown Light Rapid Transit Signalling Page 12 of 12

RAIL SIGNALLING AND TELECOMMUNICATION SYSTEM
INTERFACE MANAGEMENT
Min Khang Ho, BSc, MSc, PMP, Perunding Eagles Engineers Sdn Bhd
Ir C.S. Chang, MBA, BSc (Eng) CEng FIET, FHKIE, FIRSE, RPE (ENS, INF, CAI),
Tres Engineering Consultant Sdn Bhd
Jun Yu Chan, BEng (Hons), Tres Engineering Consultant Sdn Bhd

SUMMARY
Multidisciplinary railway projects involve many contractors, usually coming from different countries with different
background and work cultures. The net result is a risk on interfaces whereby some of the systems / subsystems
contractor do not adequately communicate and interface to the corresponding systems / subsystems from an
interfacing contractor, in the way they are expected to. Adoption of a proven interface management process and
mechanism can certainly reduce and control the risk of interfaces to achieve on time delivery of the project and
within the pre-approved cost budget.
In this paper, the authors aim to provide an overview of an Interface Management framework using real life
examples from a recent mega size metro project in South East Asia, to illustrate the applicability of the
framework, highlight the difficulties encountered and the solutions implemented to overcome these challenges.
This paper will cover three main significant interfaces related to the Signalling, Telecommunication and Rolling
Stock systems.
1 INTRODUCTION
Modern railway systems are complex and require a high level of integration of sophisticated interfaces. In order
to maintain and ensure seamless system integration, it is vital to adopt an established and proven interface
management process and mechanism. This will lead to achievement of correct interfacing and integration,
leading to the successful delivery of the project on time and within the pre-approved budget. System integration
ensures the rail system, trains and infrastructure, combined with operations and maintenance inputs, delivers a
resilient operational railway meeting customer requirements.
Key aspects of system integration and system interface management include:
• Interface Management Process;
• Interface Management Documentation;
• Tracking and Monitoring of Interface Development and Implementation; and
• Verification and Validation of Interfaces Design and Implementation.
This paper will cover three main significant interfaces related to Signalling and Telecommunication systems, they
are:
• Signalling and Telecommunication interface;
• Rolling Stock and Signalling / Telecommunication interface; and
• Signalling / Telecommunication and Civil Works interface.

2 INTERFACE MANAGEMENT FRAMEWORK

2.1 Interface Management Process
System interface management for a mega railway project can only be successfully implemented when a proven
interface management process and mechanism is established at the outset of the project. Such system has to be
properly set up at the planning stage of the project and operated by a team of professionals. This is usually
called the System Integration team who manages the System-System and System-Civil interfaces throughout the
project. The System Integration team shall adopt a series of proven interface management processes and
mechanism to reduce and control the risk of the interfaces. Such processes and mechanisms include organizing

Rail Signalling and Telecommunication System Interface Management Page 1 of 8

and leading regular interface workshops and weekly interface meetings to get the interfacing contractors to
properly and timely communicate with each other.
2.2 Interface Management Documentation
In every railway project, interface design is a process that begins in the Conceptual Design stage and will
continue all the way to the end of the Final Design. Interface design requirements are identified for each
functional interface and physical interface. To ensure full traceability, documents including Interface Specification
(IS) from the client and the Interface Management Plan (IMP) and Interface Contract Document (ICD) from the
contractors are required to be produced for each pair of interfacing contractors. [1]
2.2.1 Interface Specification
The Interface Specification, as part of the contract document, describes the interface responsibility between the
two interfacing parties. It is developed as part of Particular Specification as a common document for the two
interfacing contractors that are contractually bound. The Interface Specification will be used as basis to develop
the Interface Management Plan and Interface Control Document.
2.2.2 Interface Management Plan
An Interface Management Plan (IMP) defines a mutual agreement between the two interface contractors. It
details the approach to be adopted in progressing the associated interfaces that will cover the whole project
lifecycle from design to the testing and commissioning stage till the system is fully accepted by the client.
An Interface Management Plan covers the following subjects:
• Identification of the sub-systems or sub-system components that require interfacing;
• Assignment of responsibility and authority for interface management in both the interfacing
organizations or groups;
• Specification of the information to be exchanged over the interface with references to Interface Control
Documents providing precise technical definitions of interface data flows and protocols;
• Identification of the interface requirements including the scope of works, design, development,
installation, integration, testing and commissioning of the sub-systems;
• Indication of requirements for coordination of civil works and other facilities associated with the
interface;
• The technical strategy for developing, testing and deploying the interface including specification of the
requirements, design and testing documentation required;
• Establishment of development schedules and resources required including the relationship between
interface development milestones and overall project milestones;
• Specification of the management and technical skills required for the associated development work, at
each phase of the developers' project life cycle;
• Configuration Management and Quality Management procedures relevant to interface development
including identification of major reviews;
• Interface development risks and risk management strategies;
• A functional safety management strategy (if applicable) including references to an interface hazard
analysis.
2.2.3 Interface Control Document
An Interface Control Document (ICD) describes the details of the interface between two interfacing contractors. It
shall include all the technical and non-technical details of the interface and shall provide a full picture of the
roadmap for the design, implementation and testing of the interface between the two interfacing contractors in
order to meet the requirements as stipulated in the Interface Specification. This is thus to control and manage all
the interface related works for the two interface contractors with one being the lead and the other to match. In

Rail Signalling and Telecommunication System Interface Management Page 2 of 8

any case, Interface Control Documents (ICD) are jointly produced and signed off by the two interfacing
contractors concerned and it is a live document being maintained throughout the whole project lifecycle.
Interface Control Documents can be categorised into 2 main types for railway project:
• System to System Interface Control Document
The System to System Interface Control Document typically addresses the following interface items
between parties: Physical interfaces, Electrical/Mechanical interfaces and Functional interfaces on
design, development, installation, inspection and testing & commissioning (T&C) as well as Verification
and Validation (V&V).
• System to Civil Interface Control Document
The System to Civil Interface Control Document typically addresses the following interface items
between System works and the Civil Works: room access and provision, platform access and
provision, trackside access and provision, cable containment, power supply, air-conditioning, delivery
route and penetration requirement.
2.2.4 Interface Design Change Process (IDCP)
Throughout the project life cycle, it is not uncommon to have changes on the interface requirements so as to
facilitate the installation, correct errors and minimise risk.
The Interface Design Change Process (IDCP) ensures that:
• All proposed changes to documentation for the contractors interface requirements are reported,
recorded and resolved;
• Change instructions are presented in a clearly stated and consistent manner;
• Proposed changes are fully evaluated and properly managed;
• Full visibility on the status of all changes is provided; and
• All communications and circulation paths are well defined.
Figure 1 below illustrates the process adopted to implement a change to the Interface.

Rail Signalling and Telecommunication System Interface Management Page 3 of 8

 Contractor A identifies Contractor B identifies
need for Interface need for Interface
requirement change requirement change

Interface Requirement
Change Reports

Review of proposed Re-work and Re-submission by

change by PDP Contractor
meetings as required

No
Agreement of
change by all?

Yes

Cross Sign-off
and ICD
updates

Contractor A makes Contractor B makes

changes to design if changes to design if
required, using internal required, using internal
Engineering Change Engineering Change
Process Process
Figure 1: Interface Design Change Process
2.3 Tracking and Monitoring of Interface Development and Implementation
2.3.1 Design Coordination
During the design stage of the project, extra attention is required to coordinate the multiple system interfaces.
This coordination effort is required not only to ensure the design work be carried out on time and also to facilitate
the subsequent installation, inspection, testing & commissioning (T&C) works to avoid future disputes that may
arise during the site implementation stage.
Figure 2 below shows the coordination effort put in to achieve proper building to building external duct pit
assignment.

Rail Signalling and Telecommunication System Interface Management Page 4 of 8

 Figure 2: Well-Coordinated Duct Pit Assignment
Figure 3 below shows the progress of the Combined Services Drawing (CSD) / Structural Electrical and
Mechanical (SEM) coordination work for a major railway project.

Figure 3: Combined Services Drawing (CSD) / Structural Electrical and Mechanical (SEM) Work Progress Matrix
2.3.2 Progress Tracking Matrixes
As the project develops into the construction stage and site condition constantly changes, proper tracking and
documentation of the interface related works are required to ensure that the contractors achieve the specified
requirements. Various reports are produced to provide the project management team up-to-date information
about the status of the interface works. Figure 4 below gives an example of progress report template which is
used to monitor the civil works provision in a single table.

Figure 4 Example of Civil Work Provision Progress Report

2.4 Verification and Validation of Interfaces
It is crucial, for a mega railway project, to ensure all interface requirements are met by the interfacing contractors
so that the end product is designed and developed to meet the specified requirements. Verification and
Validation (V&V) process requires the contractors to demonstrate compliance with the specified interface

Rail Signalling and Telecommunication System Interface Management Page 5 of 8

requirements set forth in the contract with documentation evidence, e.g. test reports of the relevant interface
tests. Where necessary and for the safety critical system interfaces, independent safety assessment would be
required to certify that the interface is properly designed and implemented to meet the required safety
requirements. [2]
2.4.1 Compliance Matrix
A compliance matrix is a useful cross-referencing tool widely used in the railway industry. It is used to show the
compliance of all related contract specification and requirements and referencing to the corresponding clauses in
the Interface Control Document (ICD). This compliance matrix is required as an appendix for the Interface
Control Document (ICD) submission mentioned in Section 2.2. A sample of such matrix is shown in Figure 5
below for reference.

Figure 5: Interface Compliance Matrix

2.4.2 Interface Tests
Interface tests are to demonstrate that the major system interfaces have been implemented in accordance with
the interface design to perform the specified function. Interface tests, including both off-site and on-site tests, are
essential to ensure problems are detected and resolved as early as possible and ensure the project can be
delivered in the predefined timeframe. As noted above, the ICD is considered to be a living document and will be
populated with the interface test cases when they are identified. These are used to support the development of
the interface test procedures for validation of the requirements. [3]
2.5 Major Challenges and Solutions
In this section, challenges encountered in managing the system interfaces for a mega railway project are
discussed and the possible solutions to address these issues are also included with an attempt to address each
of these issues. Case studies with real life examples for the 3 main interfaces of Signalling, Rolling Stock and
Telecommunication systems are used to illustrate the solutions proposed.
2.5.1 The Challenges
Complex railway projects are typically delivered in multiple specialist contract packages in order to allow the
client to mix and match the best combination of specialist systems to achieve cost effectiveness, optimised
selection and control of the suppliers. Yet such a multiple contract packaging approach will result in requiring
these contractors to closely interact with one another throughout the project lifecycle in order to ensure delivery
of a seamless fully integrated railway solution. Challenges on the integration of multi-disciplinary systems
involving both hardware and software coupled with the differences in culture and practices being adopted by
different contractors from different countries will sometime result in having confusion, frustration and even
conflicts. This becomes worsened when each contractor is given a project schedule which may not be totally in

Rail Signalling and Telecommunication System Interface Management Page 6 of 8

synchronisation and the project always ends up with conflict in resources such as room access, possession
booking for Track Related Installation Programme (TRIP), work train availability, etc.
Alignment of the objectives of project management team and all contractors involved in the interfaces is critical in
ensuring all parties are working towards the same goals, with clearly defined methodology to resolve any issues.
Factors that will have significant impacts to the success of the implementation of the Interface Management
system include:
• Culture: the attitudes, values, behaviour and working environment of the client organization and the
contractor(s);
• Execution Process: the project management systems, processes and procedures that are used to
define interface boundaries and develop interface agreements;
• Information shared: the data elements that are used to define interface points and processes;
• Barriers: obstacles such as possible conflicts on the roles and responsibilities between the contractors
in the interface work.
In order to address the above interface related issues, the following points are considered crucial:
• Early establishment of clear roles and responsibilities;
• Open and effective communication among all stakeholders;
• Timely and productive interface meetings and workshops with proper leadership;
• Team culture fostering trust, honesty and common shared values;
• Adequate definition of the Interface Requirements; and
• Use of effective common Interface Management tools from the beginning of the project.
2.5.2 Case Study 1 – Rolling Stock and Signalling System
During the System Integrated Test (SIT) of a mega railway project, it came to light that, upon train start-up,
Signalling System automatically triggered the emergency brake and required to be reset by the operator
manually. This was a major problem particularly in a driverless railway environment.
After thorough investigation over a period of time, the problem was caused by the design of the safety loop
(through relays) of the train in relation to the On-board Signalling System monitoring these relays to command
emergency brake relay for driverless operation for safety reasons. While the train brake test was part of the
routine train start-up checking procedure, the on-board Signalling system would always trigger the emergency
brake during this start-up procedure. Once the emergency brake was applied by Signalling System, it was
designed to remain activated until it was reset by the operator.
The problem was finally resolved by implementing a software change in the on-board Signalling system to
recognise this start-up procedure in order to skip this emergency braking triggering. It took months before this
issue was satisfactorily addressed; particularly as it is a safety related function. This illustrates the importance of
specifying correct interface designs up to final design and testing stages.
2.5.3 Case Study 2 – Cost of Changes to a System’s Final Design
Changes after the Final Design of a system is completed always introduce significant time and cost impacts to
the project particularly if the changes are involving multiple interfaces across different contractors. A recent
example from a major railway project required that additional alarms relating to more than 200 interfacing points
per train were raised for the rolling stock resulting in major changes to the interfacing Signalling and SCADA
(Supervisory Control and Data Acquisition) systems, after final design of all these systems was completed and
accepted.
In order to contain the impacts, numerous workshops and technical meetings were held to identify possible
solutions that can minimise the scope of changes to Signalling and SCADA systems. Each interfacing point
change is estimated to cost more than USD125 to the SCADA system (software reconfiguration and testing) for a
total of 12,000 points for the whole fleet of trains. For the Signalling system, limitation on the number of

Rail Signalling and Telecommunication System Interface Management Page 7 of 8

interfacing points per train of the approved design would cause major re-design of the system should that 200
points be incorporated. The outcome in both cases would be significant time and cost impacts.
This late change had finally resulted in abortive work for both Signalling and SCADA systems with additional cost
and time incurred to the overall project.
2.5.4 Case Study 3 – Improper implementation of an interface function resulting in failure of another
Interface
One of the major problems encountered during the trial operation of such a large metro system was the failure of
on-board Public Address System (PA). Further investigation reviewed that it was the implementation of the
Signalling System to Rolling Stock interface which caused that on-board PA system to fail.
Each train was designed to have two cabs, one at each end, with only one cab “active” as determined by the on-
board Signalling System that was linked to the direction of travel of the train. This was controlled through a direct
interface between the train (rolling stock) and the Signalling System. When the train performed the “creep and
jog” function, the train might reverse the direction of travel for a short period of time. This reverse in travel
direction resulted in a momentarily switchover of the “active status” of the two cabs. In response to this
switchover, the on-board PA system that was controlled by the train radio interface unit, supplied by the
Telecommunication contractor, was also switched back and forth resulting in system hang-up due to this
momentary change. The on-board train radio interface unit was designed to follow the active train (rolling stock)
on board equipment.
To overcome this problem, it was finally decided to change the design of the on-board train radio interface unit to
be independent to the train travel direction. The active on-board train radio interface unit shall continue to operate
irrespective of the direction of the travel of the train. The on-board train radio interface unit will only switch over to
the standby system when the active system fails to function or it is manually triggered by the Operation Control
Centre operator. In addition, a Special Operation Procedure (SOP) is developed to guide the operator and
maintainer to properly manage this function.

3 CONCLUSION
As technology advances, fully integrated automatic railway systems are becoming a norm. Systems that used to
be operated in standalone mode are now required to be properly integrated to ensure an effective and efficient
yet safe railway is delivered to serve the ever increasing customer’s demand. To achieve this level of seamless
integration, systems interfaces and integration present a real challenge to all stakeholders of the system
including the client, the project management team, the contractors, the consultants and the operators and
maintainers of the system. In-depth practical knowledge acquired through years of experience is a key success
factor for railway project delivery and operation.
For the many mega-size sophisticated railway projects from Light Rail to High Speed Rail that are being
constructed and planned in the world, the establishment and implementation of a solid system interface /
integration framework and system are considered to be the foundation that will determine the success of the
railway project. The system engineers are therefore playing a key role to ensure the success of the projects.

4 REFERENCE
[1] Leong Kwok Weng, Samuel Chan, Oh Sin Hin – “Experiences on System Integration Management of
Rail Transit Projects”, 2007
[2] StKevin Forsberd, Harold Mooz – “The Relationship of System Engineering to the Project Cycle”, 1995
[3] R. Sharma – “Testing And Commissioning Process For A Light Rail Project”, 2010

Rail Signalling and Telecommunication System Interface Management Page 8 of 8