The Signalling Programme
Fjernbane Infrastructure East/West
Concept on the JOINT TEST LABORATORY.
Banedanmark
Signalling Programme
Amerika Plads 15
DK-2100 Copenhagen Ø
Denmark
Document1
Version 1.0
Author: Fjernbane Signalling
System Project.
Mail: fjernbane@bane.dk
Phone: +45 8234 0000
Phone direct:
www.banedanmark.dk
Page 2 of 37
Joint Test Lab Concept
Table of Contents
Page
1
Executive Summary
7
2
Open Issues
9
3
3.1
Introduction and Purpose
Introduction
10
10
4
4.1
4.2
4.3
4.4
4.5
4.5.1
4.5.2
4.5.3
4.6
4.6.1
4.7
4.8
4.8.1
4.8.2
4.8.3
4.9
4.10
4.11
4.11.1
4.11.2
4.11.3
4.11.4
4.12
4.13
The Joint Test Lab
Guiding Principles for the JTL
Core Objectives of the JTL
Secondary Objectives of the JTL
Stakeholders
Key Roles within the JTL
Customer
Suppliers
Third parties
Delivery Constraints
Schedule Proposal
Preconditions
JTL Practicalities
Building & Utilities
Fitment & Facilities
People
Lifecycle of the Joint Test Lab
Management of Processes
Architecture and Testing Scope
System Level
Subsystem Level
Product Level
LRU level
Types of Tests
Type of Demonstrations
13
13
14
15
16
17
18
18
20
20
20
22
23
23
26
28
28
30
31
31
32
32
33
33
35
5
Conclusion
36
Document1
Version 1.0
Page 3 of 37
History
Made by
Version
Commented by
Approved by
Status
XRZL
1.0
GULO, JHM,
GULO
Concept paper approved.
2011-06-15
LGRN. PBJ, REGA,
XDIS, XBDA,
XGER, XTGJ.
Document1
Version 1.0
Page 4 of 37
Input documents
[1] Email from XCLA referencing existing Contract Clause on JTL. 11.02.11
[2] Interoperability Assessment Modules and Process. SP-12-025541. XSMU. 16.03.11.
[3] XTGJ Minutes from Infrastructure & Onboard Workshop. 16.02.11.
[4] Criteria for the ERTMS Laboratories, v5. (http://www.era.europa.eu/DocumentRegister/Documents/Criteria for ERTMS reference labs v5 (2).pdf ).19.10.09
[5]
Document1
Version 1.0
Page 5 of 37
Abbreviations
ATC
BAFO
BDK
CA
CAB
CCTV
CSD
ERA
ERTMS
ESB
ETCS
EVC
GPRS
GPS
GSM-R
HHT
ISA
IXL
JRU
JTL
KMC
KMS
MMI
NDA
NoBo
NSA
PC
PSD
QMS
RAMS
RBC
SP
STM
TCC
TMS
TOC1
TSI
UNISIG
UPS
VoIP
Automatic Train Control
“Best and Final Offer”
Banedanmark
Certification Authority
Short for “cabin”
Closed Circuit Television
Circuit Switched Data
European Rail Agency
European Rail Traffic Management System
Enterprise Services Bus
European Train Control System
European Vital Computer
General Packet Radio Service
Global Positioning System
Global System for Mobile Communications – Rail(way)
Hand Held Terminal
Independent Safety Assessor
Interlocking
Juridical Recording Unit
Joint Test Lab
Key Management Centre
Key Management System
Man Machine Interface
Non Disclosure Agreement
Notified Body
National Safety Authority
Personal Computer
Packet Switched Data
Quality Management System
Reliability, Availability, Maintainability and Safety
Radio Block Centre
Signalling Programme
Specific Transmission Module
Traffic Control Centre
Traffic Management System
Train Operating Company
Technical Specification for Interoperability
Union Industry of Signalling
Uninterruptible Power Supply
Voice over Internet Protocol
See also the:
- Glossary List of the Signalling Programme
- Glossary of UNISIG Terms and Abbreviations (Unisig subset 023 [14])
1
Document1
Version 1.0
TOC is a Signalling Programme term. In directives etc. the official term is Railway Undertaking (RU).
Page 6 of 37
1 Executive Summary
The Joint Test Laboratory (JTL) is an initiative from the Customer in recognition of the
manifold benefits it presents to mitigating technical and schedule risks to the Fjernbane
Infrastructure and Onboard projects. Consequently it presents an opportunity for
considerable cost savings.
The JTL is a fundamental part of the Fjernbane Infrastructure and Onboard test strategies.
It mitigates risk to the projects by providing an easily accessible location to the Suppliers,
the Customer as well as relevant third parties e.g. the NSA and TOCs to either undertake
or witness a test campaign. The JTL does not substitute the Supplier’s test facilities or
obligations.
In addition, it will be possible for the Customer as well as the peer-supplier (i.e. the West
counterpart for the East Supplier and vice-versa) to observe and ensure fitment with the
counterpart system - thus ensuring an effective interface management regime and end-toend system functionality. This possibility is also shared with the ETCS Onboard System
and the GSM-R / GPRS suppliers.
Primarily, the JTL helps the Customer achieve a fully integrated and functional solution
that is uniform and seamless as far as is possible across solutions as provided by the East
and West suppliers as well as the Trainborne System Supplier respectively.
Furthermore, the JTL is anticipated to contribute hugely towards gaining the confidence
in the system that in conjunction with the test campaign on the Early Deployment line
will lead to significant time and hence financial savings at the point of roll-out of the
System across Denmark.
The co-location of the JTL members provides scope for close collaboration. This yields
benefits regarding identifying and resolving system issues that impact on functionality,
operation or maintenance – (for example by making use of test scenarios and playback of
recorded data). Co-location also provides opportunity for Customer and Supplier
personnel to gain and consolidate familiarity with the system components and associated
installation, diagnosis and maintenance equipment and methodology.
The Customer also recognises the close coupling between Joint Testing facilities and
Joint Design. Though the former can proceed without the latter, creating a JTL also
provides an environment where design options and early optimisation (through a
controlled iteration process) can occur more rapidly and efficiently - once again owing to
the co-location of the stakeholders and the relative ease of access to the products that
constitute the System.
After System handover and project closure, the JTL has potential to continue as part of
the operational system. It will hold the current baseline of the East and West deliveries as
well as access to the configuration history of hardware and software components as well
as continue to provide the simulation facilities that can be used either for specialised
training (e.g. of maintenance staff ) or for scenario investigation purposes.
In addition, any new upgrades can be fully tested both within and across systems, to
ensure compliance, compatibility and interoperability of the proposed changes.
Naturally to ensure the efficient use of the JTL, the Customer acknowledges that a range
of technical, operational and strategic management processes and procedures are called
for. Chief amongst these procedures and processes is arguably the “Configuration and
Change-Management” process, as it will be exercised throughout the lifecycle of the JTL.
Further possibilities lie in the JTL becoming an ‘Accredited Lab’ as discussed in the
Technical Specifications for Interoperability and detailed in the ISO standard 17025.
Document1
Version 1.0
Page 7 of 37
This paper recognises more analysis, consultation and strategic commitment based on a
recognised Quality Management System and peer-reviewed competence-building is
called for, in order for this potential to be achieved. It would also require organisational
separation from Banedanmark and ultimately, the SP. On balance, this paper concludes
that this specific aim is therefore not a core objective for the JTL.
Finally, the JTL can only perform optimally and provide the anticipated benefits to the
Fjernbane projects, if an investment is made in developing the supporting management
procedures - in parallel to the technical infrastructure.
Document1
Version 1.0
Page 8 of 37
2 Open Issues
No open issues are identified within this version of the document.
1.
Document1
Version 1.0
No Open Issues.
Page 9 of 37
3
Introduction and Purpose
The purpose of this document is to explore, develop and present the range of ideas and
issues that arise from the Customer initiating and developing a Joint Test Laboratory
(JTL).
The JTL will be employed as part of the overall effort required in delivering a fully
functional and integrated Fjernbane overall System, incorporating both the Infrastructure
and Onboard systems. The JTL is an integral part of the test strategies for both these
projects.
The JTL will create the required collaboration between the Fjernbane Infrastructure
System (FbIS) Suppliers, the Onboard system supplier, the GSM-R / GPRS suppliers as
well as the Customer - in order to identify, evaluate and mitigate technical and
operational risks to the Overall System.
This document discusses the introduction of the JTL but also follows up by considering
how the role of the JTL will evolve and change as both the project and the System
complete their lifecycles.
Consequently, the concepts and ideas within this document can be used to formulate
requirements and actions towards the FbIS suppliers but also the Onboard System
Supplier. Furthermore, the contents of this document also identify and address issues that
the Customer will need to resolve to prepare the way for a successful JTL environment.
3.1 Introduction
The Customer will establish a JTL. Whereby in cooperation with the various suppliers of
the systems that make up the Overall Fjernbane Infrastructure System (hereafter
discussed as the Overall System), the JTL shall contain the latest representation of the
integrated hardware and software components from all the suppliers – i.e. Fjernbane East,
Fjernbane West, and the Onboard systems respectively.
The components will be baselined and hence in a state that they can be tested
meaningfully in test cases that demonstrate the maturity, interface readiness and end-toend functionality of the overall system. This means the JTL is an important step between
testing at the supplier’s labs and testing on the running railway.
In the early stages of the Fjernbane projects, where components are still undergoing
design iterations, the JTL will contain more simulation components based on running prevalidated software programmes.
But the JTL in fact must rely on simulation engines to compensate for limitations, such
as not having real trains running (on demand) over real rails. But in so far as is
practicable, over time, the Simulation engines will make way for real products of
increasingly mature and finalised representation.
Document1
Version 1.0
Page 10 of 37
This above indicates that the JTL is foreseen to play a role in the Joint Design activities
planned by the Customer to achieve common and seamless functionality between (and
across), critical system components employed in the FbIS east and west deliveries. This
applies for example to the hand-held terminals, the dual-mode Balises (i.e. Balises
supporting GPRS for ETCS), the on-line Key Management System etc. Furthermore, it
also applies to the delivery of the ETCS Onboard System.
As ERTMS test labs already exist and all the ETCS suppliers claim to have Lab facilities
to undertake and support factory testing, one may wonder why the Customer is pursuing
test lab facilities. The answer lies in the benefits foreseen by the Customer through the
creation of a Joint Test Laboratory environment, owned and administrated by the
Customer.
In this way, the Customer can provide an arbitration role as well as an environment that
(because it houses all the offered systems making up the FbIS), offers the valuable
advantages of proximity, visibility and co-location of people and equipment such that it
can speed up identification, prioritisation and resolution of any issues that are discovered.
In this way, the technical risk and its components are considerably diminished and can
then translate to more confidence in delivering the Overall System.
Hence the JTL is foreseen by the customer as a locus of installation, Test &
Commissioning, maintenance, Diagnostics as well as Configuration & Release
management activities - in conjunction with other engineering processes that together
demonstrate the viability of the overall System.
This demonstration not only offers the evidence to the Customer but also to key third
parties such as the independent assessors, NoBos and the National Safety Authority
(NSA).
The Customer appreciates that the JTL is not an alternative to testing conducted in-situ on
the running line but rather a strong complimentor that proves the System ready for line
testing – thereby avoiding waste of costly resources.
Conducting line testing only once the systems are proven in the JTL also mitigates those
basic problems such as interface matching or hardware / software configuration matching.
Such problems are indeed much easier to resolve within a lab environment, (making use
of real products) rather than on the line, normally under ‘possession-window’ time
pressure.
Subject to final planning and agreement, the Customer deduces that the JTL must be
ready at the start or as early as possible within the design phase pertaining to the Onboard
Contract – as this is in the lead with respect to the time schedule. Fulfilling this will
allow timely and effective participation of the Customer with the Supplier, but in addition
allow effective participation of all stakeholders in the Joint Design exercise.
Having the Lab available as early as possible maintains the interoperability and
integration design criteria at prominent visibility whilst delivering the respective projects.
Issues can rapidly be discovered and can therefore be addressed a lot sooner in the
lifecycle.
Document1
Version 1.0
Page 11 of 37
This notion is the cornerstone of the so called “Iterative Confidence Growth Model” for
making best use of the JTL as the projects develop.
In basic terms, the model follows the following steps for a product to be used as part of
the overall System:
1. The Suppliers complete prototyping of products with input from the Project team.
2. Subject to the needs for proprietary factory environment testing, Prototype
testing is then completed in the end-to-end environment of the JTL (i.e. Joint Lab
FATs).
3. JTL integration testing (i.e. basis for Site Integration Testing on the Early
Deployment Sections).
4. Initiating Early Deployment Sections (EDS) with extensive nightly testing –
leading to the fine tuning of the JTL as a result of validation on the real line as
well as Site Acceptance Test (SAT) results.
5. EDS operations - leading to further fine tuning of the JTL as required by changes
in Configuration / Release status of the Overall System or its components.
6. JTL holds strictly controlled System Baselines – used as the reference /
demonstration of engineering for the roll-out lines.
7. Roll out of the System on the remainder of the railway network. This stage
benefiting from reduced-line-testing as a result of confidence gained through
earlier steps.
Document1
Version 1.0
Page 12 of 37
4 The Joint Test Lab
4.1 Guiding Principles for the JTL
The following points articulate the guiding principles from the perspective of the BDK
Signalling Programme with respect to the JTL. They are further expanded and elaborated
within specific subsections of the document below.
1. The JTL will be established by the BDK SP Fjernbane Infrastructure Project
utilising a sub-project to deliver the JTL.
2. The JTL will be used both within the lifecycle of the Fjernbane Projects (i.e. up
to formal project closure, once System Commissioning and Handover is
completed) and also within the Operational life of the Overall System. This sets
the Operational lifetime of the JTL up to the year 2046.
3. The JTL and its contents are the property of BDK – throughout its Operational
lifetime.
4. The JTL provides mitigation of technical risk that in turn mitigates project
delivery risk.
5. The JTL will act as a common and co-located platform representing both the
FbIS East and West deliveries from the two respective suppliers as well as the
Onboard Supplier.
6. The JTL project will be responsible for providing a location for the JTL in the
greater Copenhagen Area with appropriate coverage from the BDK GSM-R /
GPRS network.
7. The JTL project will also be responsible for providing the interface to the BDK
FTN and the ESB.
8. The JTL project will ensure its delivery milestones are arranged in such a way as
to provide overall benefit to the FbIS project by being able to provide testing and
simulation facilities to the FbIS project and the Onboard project. This includes
the infrastructure to conduct “Joint Lab FATs” – already specified as programme
milestones to coordinate deliveries between the individual Suppliers.
9. The JTL testing and simulation facilities will be provided through representative
sets of integrated hardware and software provided by the FbIS East and West as
well as the Onboard Suppliers respectively.
10. The JTL will provide an environment demonstrating the current baselined overall
System (across Suppliers), as well as the test platform for testing SW and / or
HW upgrades related to all or any of the constituent systems.
11. The Integrated Hardware and Software representing the current baselined
System, will be subject to configuration management processes – including
“change”, “approval”, “acceptance” and “release” principles.
12. Prior to ‘final handover and acceptance’ of the FbIS by BDK, the JTL will be
used to support and demonstrate results for system testing and usability which in
turn provide the necessary evidence to achieve the NSA approvals and the
Customer acceptance of the offered systems.
13. Post ‘final handover and acceptance’ the JTL will be maintained by BDK and
will continue to be used to demonstrate the baselined versions of the overall FbIS
systems as well as act as a repository for all previous baselines and interim
configuration builds.
Document1
Version 1.0
Page 13 of 37
14. Post ‘final handover and acceptance’ the JTL will be maintained by BDK and
will continue to provide Simulation facilities for the FbIS East and West Systems,
as well as the Onboard System.
15. The JTL will be treated as an asset for BDK and will be subject to management
processes commensurate with the stage of the lifecycle it has reached.
16. The JTL management processes will be owned and implemented by BDK.
17. Where possible, the JTL subproject will endeavour to reduce JTL lifecycle costs
by seeking to share or lease resources such as building facilities, furnishings,
telecommunication facilities, specialist lab software and tools over the JTL
operational lifetime.
18. An independent management infrastructure will be created and equipped with
corresponding management processes to ensure the continued benefit of the JTL
through its lifecycle.
4.2 Core Objectives of the JTL
Core Objectives determine the core activities that will be undertaken within the JTL.
The rationale of these activities is such that once completed, confidence will be achieved
in the systems being delivered by the various suppliers and the reliable interaction with
each other. This factor puts the focus on the “project phase” of the JTL lifecycle,
regarding the majority of the core objectives.
The assumption therefore, is that once a working overall system is delivered, any further
changes, modifications or upgrades will be both backward compatible and under strict
configuration management. This way, should a (proposed) change destabilise the
baselined working overall system, the JTL would “discover” this risk as a result of the
mandatory testing and hence prevent the proposed change from impacting the operational
railway until it is properly resolved.
The rationale for the above argument is that once the overall system is proven, it is a
question of maintaining the interoperability achieved across the Eastern and Western
deliveries - in conjunction with remaining interoperable with the trainborne subsystem.
In fact, as the scope of the Overall System goes beyond ERTMS systems – where the
term “Interoperability” has gained a reserved meaning, it would be correct of this paper to
use the term “Intraoperability” of all Systems that have a role to play within the Overall
System.
The core objectives for the JTL are hence proposed as follows:
1. Supporting the Joint Design process
2. Exercising the System solutions through trial and feedback processes
3. Minimise risk and cost exposure arising from conducting tests on the line-side.
4. Use the JTL for test campaigns to iteratively grow the confidence in the System,
such that the testing evidence contributes to the NSA Approvals and Customer
Acceptance of the delivered solutions.
5. Demonstration of Products , Tools and Methodology
6. Demonstration of Interface, functional, and non–functional behaviour.
Document1
Version 1.0
Page 14 of 37
7. Demonstrate the progressive maturity and completeness for the novel design
elements of the delivered System – (e.g. Online Key Management, GPRS based
communication etc.)
8. Demonstration of the maturity of the Overall System design for the stage-gate
review process
9. Be used to resolve Interoperability issues amongst the JTL members.
10. Compatibility testing and demonstration within and across delivered systems.
11. Conducting Validation campaigns on novel Traffic Management Processes across
the Overall System.
12. Demonstrate the technical solution compatibility with the operational-rule set.
13. Contribute (mainly through simulation or analysis of real data), to the validation
of ETCS configuration parameters.
14. Contribute to Safety Case elaboration / update - by the JTL acting as a source of
reliable test evidence.
15. Contribute to validation of supplier Release Notes.
16. Allow interaction between technical, operational, maintenance and management
staff.
17. Demonstrate a clear boundary between System builds and Releases both during
project evolution and after formal acceptance and handover of the project.
18. Provide simulation and playback facilities either from recorded events (e.g. from
JRU data) or from scenario configuration tools as part of Simulator engines.
19. Protect the Service level agreement goals by avoiding System errors progressing
into the operational railway environment.
20. Act as the BDK in-house expert on interoperability and as such be able to
confirm that overall system interoperability and compatibility is retained as the
two infrastructure and the onboard subsystems are upgraded.
21. Retain an archive of hardware and software baselines and corresponding
documentation (particularly in electronic format) to allow access to and
demonstration of a particular baseline of the system - throughout its design
lifecycle.
22. Provide validation (when necessary) of test results from other test laboratories
given identical test cases and system configurations.
4.3 Secondary Objectives of the JTL
Maintaining the continued interoperability of the overall system is the foundation for
determining the secondary objectives of the JTL.




Document1
Version 1.0
Demonstration of Baselines and application of Configuration management and
Interface Register practises.
“Sand box” environment for Maintenance practise to help maintenance staff gain
confidence and familiarity with products, tools and processes.
Access to Simulation environment for Maintainers and experienced Operational
Staff. As opposed for general classroom / education purposes.
Assist in defining the boundary for testing based on the idea of “regression
testing”.
Page 15 of 37
4.4 Stakeholders
Over its lifecycle, the JTL has to satisfy a diverse range of interests and demands from a
range of stakeholders.
Although all stakeholders share the common interest, that is, to achieve and maintain an
integrated and fully functioning end-to-end overall System solution, it is also recognised
that stakeholders may hold specialised interests in the JTL.
The table below lists the stakeholders contributing to and benefiting from the JTL as well
as indicates sensitivity to the fact that stakeholders may hold specialised interests.
Furthermore it is also important to note that specialised interests can be an ‘emergent
property’ of interacting with the JTL and can therefore change in both nature and
intensity over time. This fact suggests further management procedures, aimed at
stakeholder management is required when employing the JTL.
Stakeholder
Document1
Version 1.0

BDK

Certification Authority (NoBo)


Civils Contractor
European Rail Agency (ERA)

Independent Labs e.g. CEDEX

International Neighbours



Other Supplier Labs (UNISIG
Members)
Others
Supplier - East

Supplier - Onboard

Supplier - STM

Supplier - West

The Onboard project
Specialised Interest
Benefit from the JTL as a recognised national centre
of excellence for ERTMS testing of Baseline 3
products.
Early exposure to ERTMS system architecture and
behaviour. Evidence base to progress assessment
and certification tasks.
None identified.
Change request and / or Validation data Input. JTL
can be source of real data on system behaviour
completeness and performance against ETCS
Specifications.
Share Best practise on Test Cases and Tools and
(perhaps) ensure market share is not “eroded” to
another test lab.
Ensure compatibility of technical and operational
interfaces.
Other Labs arguably offer an alternative test path to
ensure ETCS interoperability issues do not arise.
None identified.
The progress and effective performance of peer
suppliers.
The progress and effective performance of peer
suppliers.
The progress and effective performance of peer
suppliers. But also to verify STM operation in
transitions to and from ETCS and using such results
to reduce the safety-case documentation overhead.
The progress and effective performance of peer
suppliers.
Ensure Onboard delivery is compatible with
Infrastructure solutions from other UNISIG
Page 16 of 37
Stakeholder

The Signalling Programme

TOCs – e.g. DSB

Witnesses - e.g. NSA, G-ISA,
Specialised Interest
Suppliers. Also to:
 Perform Integration trials during Joint
Design Phase.
 Run scenarios to validate equipment
functions safely and correctly.
 Generate test based evidence to reduce the
safety case overhead.
 Validate transition from ETCS baseline
2.3.0d to baseline 3 for the Onboard
System.
 Validate transition to the national
signalling system for train protection, by
means of the respective STM solution for
Denmark, Sweden and / or Germany being
fully functional.
Effective introduction of the JTL as well as
ensuring maturity of processes such as Operational
Rules are ready and available.
Early exposure to System behaviour and input on
end-user issues. Also to facilitate stakeholder
processes for themselves and other groups such as
trade unions, drivers etc.
Early exposure to System behaviour and input on
Safety-Approval / Safety-Case issues.
As important as identifying the stakeholders, is identifying possible conflicts of interest or
even grounds for potential conflict in accessing, using and responding to the JTL test
campaign results.
In response to this potential risk, we propose that management procedures are put in place
as a precondition to initiating the JTL. The role of the management procedures is
developed further in a specific subsection below.
Within this document the term “JTL members” is used to describe the group of
stakeholders consisting of the Customer and the individual suppliers.
4.5 Key Roles within the JTL
The following subsections propose which activities within the scope of the JTL, will be
led by the Customer, the Supplier and / or 3rd parties respectively. In other words, “who
does what”.
This section can, (once agreed by all JTL members), form the basis of a Work Breakdown
Structure and hence a JTL project plan. This of course, requires time-schedules,
durations and dependencies to be properly clarified.
Document1
Version 1.0
Page 17 of 37
4.5.1
Customer
The customer will lead the following activities and ensure coordination with other JTL
members:
1. Initiate and establish the JTL building.
2. Facilitate access to the GSM-R network and eventually also access to the GPRS
network.
3. Provide the interface to the FTN including Internet access authorisation from
BDK IT.
4. Provide the interface to make use of the Enterprise Services Bus and / or other
external interfaces.
5. Provide the necessary Insurance and liability cover
6. Facilitating the use of a “first-of-class” train equipped with both ETCS and STMDK.
7. Provide and maintain the utility infrastructure for the JTL.
8. Establish, agree and supervise the Management processes and procedures.
9. Establish and administrate the booking, access and use of the JTL for Customer,
Supplier and third-party staff.
10. In collaboration with the other JTL members, establish the “Central Control
Area” of the JTL based on agreed System interfaces.
11. Establish the benefit of, and thereafter source the lab specialised software and
diagnosis tools that will facilitate the “trouble-shooting” and integration of the
diverse solutions from the Suppliers. – This will help achieve the end-to-end
functionality demonstration of the Overall System.
12. Coordinate and supervise the integration testing campaigns.
13. Review, validate and accept test documentation for such campaigns.
14. Arbitrate test results, actions and objectives amongst the JTL members.
15. Coordinate and supervise the resolution of System issues and / or anomalies.
16. Coordinate the involvement and witnessing of testing by 3rd parties, particularly
the ISA, the NoBo and the NSA.
17. Coordinate and supervise the correct use of the System Interface Register as per
information and data agreed with all the JTL Members.
18. Create and administrate the correct and effective use of a common ‘System
Anomalies Database’ for the JTL members.
19. In collaboration with the other JTL members, lead the Escrow arrangements for
managing software baselines.
20. Retain accountability for Overall System integration
4.5.2
Suppliers
The Supplier is required to lead / assume responsibilities for the following activities:
1. Elaborate and present a System Integration Plan detailing preparation and use of
the JTL.
2. Supply products and subsystems that are successfully factory tested and certified
where applicable.
3. Provide current baselined hardware and software packages.
4. Install, test and commission integrated products within the corresponding
Subsystem to build a representative and physically accurate instance of the
Supplier’s delivery – including those parts that are allocated to the CentralControl-Area of the JTL.
Document1
Version 1.0
Page 18 of 37
5. Install, test and commission “simulation engines” within the corresponding
Subsystem - where a representative and physically accurate instance of the
Supplier’s delivery is not practically possible within the JTL environment.
6. In collaboration with the Customer, assist in completing the “Central Control
Area” of the JTL.
7. Contribute to the identification, evaluation, trial and adoption of any specialised
lab software and / or diagnosis tools that improve the efficiency of the JTL
efforts.
8. To ensure the successful interfacing of the overall System and having it
represented within the JTL environment, undertake to provide the agreed
interface and data protocols.
9. Configure and label all products, wiring, and interface junctions as agreed with
and directed by the Customer.
10. Provide and Maintain the documentation corresponding to the Solution delivered.
11. In conjunction with the other JTL members, and relevant 3rd parties, participate in
the Escrow arrangements for managing software baselines.
12. Undertake to maintain their respective part of the JTL in full working order in
accordance with maintenance agreements currently in place. This may include
providing maintenance training to a subset of Customer Staff and other such
maintenance related requirements.
13. Ensure accuracy of Configuration Management Process Records.
14. Establish and deliver timely statements of formal product and System baselines
by means of “Release Notes” or equivalent method as agreed with the Customer.
15. Ensure timely adherence to the change and configuration management process as
agreed with and directed by the Customer.
16. Provide a “Test Engine” computer that (if necessary), in conjunction with a
“Simulation Engine” computer, facilitates the choice for testing and / or playback
scenarios - based on Software and data configuration parameters - applied to a
specific hardware baseline.
17. Collaborate and cooperate with the Customer and peer suppliers in order to
establish and maintain a JTL environment that supports end-to-end demonstration
of the Overall System.
18. Participate in Overall-System Analysis and / or testing with a view to resolve
functional, non-functional or interface based issues and / or anomalies.
19. Employ and contribute to the common System Anomalies Database.
20. At an agreed point in System Design maturity, and in collaboration with the
Customer and other JTL members, undertake to demonstrate that the results
achieved in the Lab may be validated by real line behaviour.
21. Subsequently and as agreed with the Customer, undertake to complete any
required iteration to ensure that lab results are indeed valid and may (once
approved and accepted) be used a sound platform to prepare line-side test
campaigns.
22. Ensure adherence to the agreed Management Processes including Security,
Access rights, Staff and / or Sub-supplier Management and Non-Disclosure
agreements.
23. Provide tools, manuals and training to the Customer JTL members to ensure
proficiency in using and exercising the delivered system.
24. Should the Supplier incorporate COTS products into the delivered System, then
the Supplier will also ensure to also provide a copy of the corresponding device
drivers as part of the Baseline package.
Document1
Version 1.0
Page 19 of 37
25. Facilitate response and closure to input from third parties such as the TOCs, the
ISA, the NoBo and the NSA.
26. In the event of the Customer exercising an option, then the Supplier will assist
and participate in the new configuration of the JTL to represent the new baseline
of the overall System.
27. Up to the point of formal handover, provide the requisite human resources to
ensure the JTL remains operational and up-to-date with respect to the delivered
system representation.
28. Comply with JTL management procedures.
4.5.3
Third parties
The following activities will be allocated to 3rd parties:
 Witness test results either with an assessment viewpoint or certification
viewpoint.
 Validate the “release” and “acceptance” documentation sets, with a view to
provide “Approvals”
 Comply with JTL management procedures.
4.6 Delivery Constraints
At a global level, the JTL can only play its part fully if it is established and delivered in
time to assist with the Joint Design Phase of the Fjernbane Infrastructure and Onboard
projects.
As the JTL will accommodate equipment from all the Fjernbane Projects and as the
Contract will be let for the Onboard project approximately 3 months before the
Infrastructure projects, availability of the JTL is more critical for accommodating the
Onboard schedule.
However, it is prudent to avoid unnecessary dependency amongst the projects that may
create “artificial” time pressure on delivering the JTL. One example of this, is the
Onboard objective of using the ETCS 2.3.0d baseline – which in fact is out of scope for
the Fjernbane infrastructure projects. Hence this would suggest a convergence on using
JTL facilities not on the availability of 2.3.0d products but rather on the design activities
for the baseline 3 product range.
This argument is the basis for the proposed JTL commissioning date as discussed in the
section below.
4.6.1
Schedule Proposal
The date for the Onboard System’s preliminary design requirements to be in place is
scheduled for 01-May-2012, whilst agreement on the Joint Test Lab facilities with respect
to the Conceptual Design, is scheduled for the 30-March-2012. Treating this as the
Document1
Version 1.0
Page 20 of 37
ultimate delivery date for the JTL, implies a “commissioning” date in the first quarter of
2012.
As a working assumption for the purpose of this document, the 30-March-2012 is
nominated.
However, as the following high level time plan demonstrates, applying some logical and
reasonable durations and dependencies suggests a more realistic commissioning target (at
the earliest) to be circa 01-July-2012.
An accelerated and / or intermediate delivery plan can still be explored at the point of
formally initiating the JTL subproject and once it is more clear what assistance can be
provided by the System Supplier’s and by when.
This means that the following time-plan schematic can be expected to undergo further
detailing and logic and there is every chance this will alter the proposed JTL
commissioning date.
Q1
Q2
Q3
Q4
Q1
Q2
Q3
Q4
2011 2011 2011 2011 2012 2012 2012 2012
Secure budget for JTL establishment
Secure budget for JTL upkeep
Establish recruitment plan
Recruit JTL Manager
Recruit JTL Staff
Conduct and Complete JTL training for
staff
Find JTL premises
Create JTL Management Processes
Furbish / refurbish premises to
accommodate JTL needs
Connect Facilities
Install Furniture and Fittings
Commission Facilities and
Infrastructure – including any access to
lab specialised software / common
diagnosis tools
Introduce Suppliers to JTL and Issue
Access Keys / Fobs
Begin to Install, Test and Commission
representative solutions from Suppliers
Prepare Documentation Library
Handover from Suppliers to BDK of
iterative, Solution-Baselines, including
corresponding documentation
Commission JTL
Document1
Version 1.0
Page 21 of 37
4.7 Preconditions
Further to the ‘Schedule Proposal’ above, this subsection lists and explains the entities
that must be prepared and / or resolved in order to ensure a smooth delivery of the JTL.
Also, and equally importantly, allow for the JTL to be used for its intended purposes.
The preconditions to smoothly delivering the JTL are proposed as follows:
1. Human Resources. The JTL requires the appropriate professionals with the
relevant competencies to deliver, administrate and manage the JTL and its
services.
2. Management Practise. Efficient processes and procedures must be put in place to
manage the flow of people, products and data that enters and / or leaves the JTL.
(Amongst others, this document has highlighted the need for strong change and
configuration management processes for example).
3. Clear Test strategy. An agreed approach to the scope of JTL testing including
when and how this will come about with respect to project stage-gates and other
milestones. The test strategy will be based on the “iterative confidence growth”
model as discussed in the introduction section of this paper.
4. Agreed Baseline approach. An agreed approach to both the ETCS product
baseline that will be introduced as well as a transparent approach on how the
suppliers will manage respective system evolutions.
5. Baseline 3 Products roadmap available. This factor aims at understanding when
baseline 3 products will become available and how we can ensure readiness for
the customer environment (including the JTL) as efficiently as possible. Not
least, this will require a level of coordination between the Suppliers, from the
Customer.
6. Location. The physical location and characteristics of the JTL must be
established. Consequently issues such as Access rights, Security, Logistics etc
can be developed and resolved.
7. Building Fitment and Furniture. Clear understanding and consensus on
infrastructure, dimensions and quantities to be agreed.
8. Establishment of Services, Utilities and Facilities as well as the access to External
Interfaces. Topics include:
- Power,
- UPSs,
- Heating /Cooling /Ventilation / Fire-Protection,
- FTN,
- GSM-R and eventually GPRS coverage
- IT,
- Security, e.g. CCTV - including archiving and playback systems
- GPS Antenna with external mast mounting
- Telephones, or as is most likely, VoIP Communication technology (e.g.
Office Communicator) running on PCs need to be sourced and activated.
9. Apportionment of Space within the JTL. Endeavour (as far as practical building
limitations allow), to create a working space that caters for:
- Common Zones – including the “Test Control Area”, thereby allowing the
JTL members to initiate, control, exchange, observe and participate in test
campaigns and results. But also, to benefit from convenience facilities such
as kitchen or bathroom services. One foreseen benefit of a common zone, is
Document1
Version 1.0
Page 22 of 37
10.
11.
12.
13.
14.
15.
16.
the demonstration of the current overall System baseline in terms of products
and interfaces.
- Supplier Zones – thereby allowing test campaign preparation, anomaly and
incident investigation as well as protect confidential information / product
status. Access to Supplier zones by default is limited to supplier staff and
BDK personnel. Third parties may gain access only by arrangement.
Establishment of Security procedures and equipment for the JTL as well as to
establish:
- Access Rights for the JTL Members.
- Access Rights (If any), for the JTL member’s Sub-Suppliers.
- Access rights for 3rd Parties, e.g. NSA or TOC representatives.
Establish and put in place procedures to ensure Confidentiality and protection of
IP. This could include:
- Drafting and signing of Mutual Non Disclosure Agreements (NDAs).
- Agreement of “House Rules” such as the exclusion of sub-suppliers from the
JTL, for example.
Familiarity training for Customer Engineers that will make use of, and administer
the JTL.
Preparation of the Documentation Library relevant to the System and its
‘baselined’ solution.
The Creation, introduction and baselining of the common Interface Register.
Subject to availability, the preparation and baselining of the JTL “System”
Including Products, LRUs, Simulator Engines, Application Data Files,
Configuration and Diagnosis tools etc. from the respective suppliers.
Availability and agreement on the Customer's baselined “Ops Rules” as they
apply to the overall System.
4.8 JTL Practicalities
The JTL will nominally be established in the greater Copenhagen area of Denmark. The
following subsection considers the practicalities of establishing the JTL. It provides some
provisional targets (which will be agreed with the respective suppliers) with respect to the
JTL building, its fitments and its people.
The targets are derived from the pre-conditions discussed earlier in the document. The
results are stated as provisional, (and for now) rather high level, Customer requirements.
4.8.1
Building & Utilities
Provisional requirements applicable to the JTL building are as follows:
Id.
1.
2.
Document1
Version 1.0
Requirement
The JTL shall have partitioned areas for use by
the separate suppliers to establish their section
of the JTL.
The walls of the partitioned areas of the JTL
shall only be allowed to move after being
Guidance / Rationale /
Substantiation
Thus creating movable partitions.
When partitions locked in place, they
Page 23 of 37
Id.
Requirement
“unlocked” to do so by an authorised person.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Upon rolling back of the partition walls, the
JTL shall be so arranged as to reveal the chain
of systems that make up the end to end
functionality of the Overall Fjernbane system.
The JTL shall be so arranged such that from
the common area of the Lab, it will be possible
to view all JTL member systems – provided
the partition walls are rolled back.
The JTL shall be equipped with one ‘Central
Control Area’ containing all relevant MMIs for
the supplier-installed systems – including the
associated simulation engine(s).
From the ‘Central Control Area’ within the
JTL, it shall be possible for a test team of 2-3
people (making use of the MMIs provided), to
run a full scale test, exercising the end-to-end
functionality of the Overall System.
Entry into the JTL building shall also be
protected with access control equipment.
The JTL building shall have a goods-handling
area.
The goods-handling area within the JTL
building shall also have a self enclosed
lockable secure area.
The JTL building shall have an external yard
for placing of physical equipment (such as
Level Crossing barriers), of at least 10 metre
width and of an area of no less than 200m2
The JTL building shall possess windows that
overlook the external yard.
To secure the external yard, the JTL shall be
equipped with security fencing and gates.
The JTL building shall be dimensioned to
easily accommodate up to 30 people working
within it at any one time across all the
individual areas.
13.
14.
Document1
Version 1.0
Guidance / Rationale /
Substantiation
contribute to privacy and security.
When rolled back, they contribute to
demonstration of the overall System.
The Customer also refers to this as the
“Central Control Area”.
The level of usage is anticipated to
peak during the project delivery phase
of the overall lifecycle – before
dropping to “operational” levels.
Working assumptions are each JTL
member will place a team of circa 7
people (approx 28 people) – dropping
to JTL full time staff + occasional
guests. Anticipated at around 6 people
+ guests.
The JTL shall be equipped with emergency
exits in accordance with Danish safety
regulations.
Page 24 of 37
Id.
15.
16.
17.
18.
19.
Requirement
The JTL shall have an office area reserved for
BDK personnel – including JTL management.
The JTL shall be equipped with a reception
area.
The JTL shall be equipped with a building
facilities and administration office.
The JTL shall be equipped with a Food
consumption space and facilities.
The JTL shall be equipped with Toilet and
Shower facilities.
The JTL shall be equipped with a Meeting
room accommodating up to 30 people.
20.
21.
22.
The JTL shall have individual Plant rooms to
accommodate the heating, cooling and
electrical supply equipment.
Each Supplier area within the JTL shall offer
at least 75m2 of useable floor space.
In order to accommodate the JTL members
needs for both private and common areas, the
total useable indoor floor space shall be no less
than 600m2
23.
24.
25.
Document1
Version 1.0
Guidance / Rationale /
Substantiation
This will provide kitchen facilities
rather than a fully serviced canteen.
To maximise space and lower costs, we
propose to use such a meeting room to
also act as the documentation library –
by providing adequate shelving on the
walls.
Applied assumptions (averaged out),
are as follows:
 3*75m2 – Supplier space,
including ‘self-enclosed’ server
room.
 1*75m2 – BDK space for goods
in, handling, archiving, CentralControl-Area, Simulation
viewings, Equipment Training,
etc.
 Subtotal = 300m2
 Then, 9 * 30m2 – (Meeting room /
Library, + Management office, +
Kitchen facilities, + Reception, +
Toilet / Shower areas, + 3 Plant
Rooms, + Access / Hallways/
Piping / Cabling risers).
 Subtotal = 270m2
 Total = 570m2
 + 30m2 tolerance factor, to
account for using lower end of lab
space estimates from suppliers
feedback & lab space experiences.
 Grand Total = 600m2
Each Supplier area within the JTL shall be
protected with access control equipment.
Each Supplier area of the JTL shall have
independent cable routing / riser paths.
Page 25 of 37
Id.
26.
27.
28.
Requirement
Guidance / Rationale /
Substantiation
The JTL shall have areas accessible to all
members of the JTL.
Supplier areas within the JTL shall be provided
with a self-enclosed Server-Room.
Both the common and supplier areas shall be
climatically controlled to automatically
maintain a temperature range of between 15
and 25 degrees centigrade.
29.
4.8.2
Fitment & Facilities
Provisional requirements applicable to the JTL fitment and facilities are as follows:
Id.
1.
2.
3.
4.
5.
6.
7.
Requirement
The JTL shall be fitted with the necessary
service utilities.
To facilitate cabling and maintenance, the JTL
shall be fitted with both false-flooring and
false-ceilings.
The false flooring of the JTL shall be able to
withstand loading pressure of 1200Kg / m2
The JTL shall have an electrical mains supply
of 240v AC.
The JTL shall also have an electrical mains
supply of 415v AC
The JTL shall be fitted with broadband
facilities
The JTL shall be provided with a redundant
access node to the BDK FTN
UPSs shall be provided at the JTL.
8.
9.
10.
11.
Document1
Version 1.0
Should back-up generators be required to
support the UPSs in the JTL, then, they shall
be located as to have them protected from fire
and flooding risks.
The JTL shall be fitted with an emergency
lighting system - illuminating (at the
minimum) the access ways and paths to
emergency exits.
Both private and common area zones of the
JTL shall be furnished with appropriate
furniture, for the corresponding purpose of the
JTL zone in question.
Guidance / Rationale
The JTL will have electricity, fresh
water and waste-water utilities.
The Customer will provide fire-walled
access to the FTN.
The UPS and back-up generators will
be scaled in agreement with the JTL
members.
This accounts for shelves, racks, test
benches, tables, desks, chairs,
cupboards, white-boards, windowblinds, etc. as appropriate for the JTL
room being furnished.
Page 26 of 37
Id.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
Requirement
Each private area shall be fitted with a meeting
table accommodating at least 8 people.
The meeting room within the JTL common
area shall be fitted with Video Conferencing
facilities.
The Meeting room space within the JTL, shall
be fitted with wall shelves to accommodate
system documentation.
Access control equipment shall be centrally
administered and configurable to allow the
required profile for each JTL User to be
applied.
Each Supplier area within the JTL shall be
protected with access control equipment.
Each Supplier area within the JTL shall
contain a series of floor level and ceiling level
power outlet sockets.
Should the JTL be arranged over several
floors, a Lift shall be provided
In the case where a Lift is provided within the
JTL, it must be able to accommodate the
height, weight, length and depth of the bulkiest
lab equipment and with manoeuvring room.
The JTL shall be equipped with a pallet trolley
to assist with transporting heavy / large boxes.
The JTL shall be fitted with a fire detection
and protection system commensurate with the
sensitive electrical and electronic equipment
housed within it.
The JTL shall be fitted with a CCTV system.
The JTL shall be fitted with an Intruder Alarm
System.
The JTL shall be equipped with a mast
mounted external GPS antenna with
connection sockets in all the private areas.
24.
25.
Guidance / Rationale
The candidate products have to be
checked with suppliers. Nominally
these may include the RBC and / or
IXL racks.
This will be managed by the Customer.
This will be managed by the Customer.
This is to cater for operating the ETCS
trackside and onboard products that
rely on the GPS signal for timestamping (e.g. the JRU). Further
refinement e.g. using the “network time
protocol” instead may be agreed with
the JTL members.
Within the Server rooms and spaces
accommodating technical equipment making
up the Fjernbane Overall System, the JTL shall
be fitted with floor coverings that do not create
the build-up of static electricity.
26.
Document1
Version 1.0
Page 27 of 37
4.8.3
People
Provisional requirements applicable to the JTL personnel are as follows:
Id.
1.
Requirement
The JTL shall be staffed with a JTL Manager
responsible for the everyday operations of the
JTL.
The JTL shall be staffed with a JTL Test and
System Configuration manager.
2.
The JTL shall be staffed with a Test
technician.
3.
The JTL shall be staffed with a Receptionist.
4.
Guidance / Rationale
Such a role will hold responsibility for
ensuring the “RAMS” of the Overall
System as well as the integrity of the
delivery from all the Suppliers –
throughout the lifetime of the JTL.
Such a role will hold responsibility for
ensuring the correct configuration and
health status of the Overall System
components as well as to organise and
supervise simulation and playback
testing and to undertake the
management of the JTL assets.
Such a role will hold responsibility for
ensuring the well-being and safety for
visitors, including the booking of
access to personnel as well as
management of goods inward and
outward of the JTL.
5.
4.9 Lifecycle of the Joint Test Lab
As with other systems, we can expect the JTL to go through phases of introduction,
growth and decline. We can also expect regular maintenance, upgrades and ultimately,
disposal. This section considers what special and foreseeable events, may have an impact
on the JTL.
For simplification the identified events are displayed within the following table, as those
that arise during the Fjernbane projects, those that come after project commissionings and
those that can occur in both timeframes.
In all cases, the JTL members must be prepared to accommodate and deal with these
events and to ensure continual benefit from the JTL investment.
Event
FbIS Overall System Upgrades
Mid-life Upgrades
Evolution of the ETCS baseline
Migrating from Simulators to Real Products
Document1
Version 1.0
Occurs During
Project



Occurs Post
Project


Page 28 of 37
Event
Availability of GSM-R and GPRS coverage
Key Management System – Offline to Online
Ensure JTL remains consistent with developments in
project phases; for example, Joint Design, Early
Deployment, Rollout etc.
Responsibilities for ‘Lot not awarded’
Incident / Anomaly Investigation
‘System Configuration’ Upgrades
External or 3rd party interface change
Centre of Excellence / ERTMS Reference Lab for CSD
and PSD operated railway evolving into an official
“Accredited” Laboratory as per TSI definitions.
Decommissioning and Disposal
Occurs During
Project


Occurs Post
Project










The FbIS solution requires the introduction of novel products, such as, dual mode RBCs,
EVCs and Balises to accommodate GSM-R as well as GPRS technology. The Customer
has also called for Hand held terminals and On-line crypto key management systems.
Naturally, development and testing of such products will also ultimately require
certification (as per the Technical Specifications for Interoperability) before these
products may be freely applied. Unless it is established that the product in question will
remain a “National Domain Product” and that it has no impact on system interoperability.
As there are only 3 “recognised” laboratories (Cedex Lab in Madrid -Spain, - having the
most established reputation for ETCS testing), equipped to complete certification
processes in Europe at the moment, and none with GPRS competence, then there may be
a time-schedule risk to the Fjernbane projects as products face certification bottlenecks.
In the face of potential bottlenecks, ERA has published a proposal [4], based on the
objectives of the ‘Standard for Accreditation of Test Laboratories’ (ISO 17025:2005),
outlining the salient points of competences and cooperation required between the Labs,
Unisig Suppliers, National members of the “Accreditation Bodies Network” and ERA.
This situation suggests that the JTL could be from the outset planned as an Accredited
Laboratory. The consideration that must be kept in mind however, is that a process based
on adherence to a quality management system (QMS) as well as evidence of technical
competence and applying that competence over time as stipulated by the requisite
standard (ISO-17025:2005) and subjected to “peer” review, is called for. Though this is
all within what the JTL could achieve, it is not compulsory for achieving the objectives of
its “core business” – as discussed in section 4.2 above.
Because of this, and despite the criticality of the need for certified products, this paper
considers the potential evolution of the JTL to ‘Accredited Laboratory’ as an event that
may occur once the System is commissioned and the project is closed. It is certain at
present that the contribution of the JTL and the continued success of ERTMS in
Denmark, up to and beyond 2021, does not depend on the JTL being a formally
accredited laboratory.
As a consequence, the Customer will therefore need the Suppliers to be carefully
prepared regarding their product roadmap strategy and going beyond testing of these
products, also declare how these products will achieve certification for use within the
BDK network.
Document1
Version 1.0
Page 29 of 37
This issue will have to be further discussed and developed with the respective suppliers
and stakeholders such as the NoBo and the NSA and the outcome reflected in planning
the JTL lifecycle.
4.10
Management of Processes
As mentioned above, embedding the JTL within firstly the SP and subsequently within
BDK, requires the creation and launch of a range of management processes as befits any
other new ‘department’.
The list below introduces some the more prominent and / or urgent processes in the
context of the JTL.
1. Establishing procedures to take ownership of the JTL products - i.e. formalisation
of the transfer of baselined products from suppliers to the customer.
2. Establishing the Escrow procedures for managing delivered baselines of Software
packages over the JTL lifetime.
3. Booking of specialised resources / people, for example to conduct a compatibility
test.
4. Responsibility for Spares for the JTL.
5. Replenishment of Spares (if and when used) for field maintenance.
6. Ensuring and Preserving compatible maintenance procedures across the overall
System.
7. JTL asset management - including inventory management and bringing in /
taking out of equipment into / from Lab.
8. Procedure to archive examples of product types / evolutions.
9. Responsibility for Obsolescence Management for the JTL.
10. Maintaining consistency with the Training and e-learning practise, (as delivered
by the Fjernbane projects) - regarding use and maintenance of equipment.
11. Consider the Interaction and knowledge sharing process with the user-support
and / or maintenance “Hotline”.
12. Ensuring accurate Configuration baselines for products,
a. including agreed “default configurations” and values
b. agreed timescales for when new baselines will be “activated” in the JTL
by the respective suppliers.
13. Establishment and benefiting from Configuration Audits.
14. Arrangements for the witnessing of Tests and reviewing test results.
15. The management of Documentation as apply to the JTL environment.
16. Arrangements for preserving Confidentiality.
17. Escalation and Arbitration process to manage JTL member issues that may arise
from the sharing of resources as well as the use and / or abuse of the JTL itself.
Arbitration may also be required for assessing results from parallel development
efforts from the Suppliers, for those areas outside Joint Design collaboration.
18. Establishing Support agreements from the Suppliers to cover the lifetime of the
JTL.
Document1
Version 1.0
Page 30 of 37
4.11
Architecture and Testing Scope
In order to be able to support and allow for various test campaigns and simulation
objectives, the JTL will be fitted out with physical examples of real equipment that
interface with each other to create a representation of the Overall System.
Where physical products are not yet available, too cumbersome for the JTL space
envelope, dependant on external interfaces, or are immature, then a simulator engine will
act as a substitute.
Simulator engines are also foreseen to be used to represent the trackside and trainborne
environment – for example to simulate a passing of a series of trains over a track section,
hence gaining an insight of how the technical system stands up to timetable and other
operational demands.
This subsection catalogues the range of products expected by the Customer to be
available within the JTL. They are organised in top – down arrangement.
The respective Suppliers are responsible for providing, installing and maintaining the
products within the JTL under the most current and customer approved Baseline. The
Supplier will also support the customer with the relevant training, tools and
documentation entities.
For the purposes of this section, products are understood as an integrated package of
hardware, software and where appropriate firmware. The product is also understood to
possess the correct and functioning interface characteristics such that several products
may be integrated to form a subsystem which in turn are integrated to form a
representation of the Supplier’s system solution.
Where applicable, the Customer also expects that the JTL will be populated by precertified products. That is to say, the Customer does not foresee the need to sponsor a
certification campaign as discussed by the Technical Specifications for Interoperability.
The following subsections provide a high level outline of the architecture and the testing
scope. The architecture is presented on a ‘candidate’ basis as opposed to the finalised
version that is yet to come.
4.11.1
System Level
The System level represents the Fjernbane East or West solutions as well as the ETCS
Onboard solution. The System level solution is essential for conducting test campaigns
leading to Site Integration Testing (SIT) and Site Acceptance Testing (SAT) evidence.
The System level also allows for campaigns to prove interfacing across the East / West
border as well as across the national borders with Sweden and Germany.
In addition, and by using Customer provided access to the Fixed Transmission Network
(FTN) as well as other IT services, it will be possible to conduct test campaigns by
networking with remote 3rd party test laboratories.
Document1
Version 1.0
Page 31 of 37
The System solution is made up of integrated subsystems as detailed in the next
subsection.
4.11.2
Subsystem Level
The JTL will be populated with the subsystems as listed below. Each subsystem will be
introduced under careful configuration management and a corresponding ‘Release Note’
document to provide assurance to the Customer that the Subsystem is properly baselined.









ETCS Trackside (East)
ETCS Trackside (West)
ETCS Trainborne (Including the Danish STM)
IXL and peripherals (East)
IXL and peripherals (West)
TMS (East)
TMS (West)
GSM-R / GPRS
KMS / CA (East and West, or as per the outcome of Option 10 in the contract).
Note that presently, with regards to GSM-R and GPRS subsystems, BDK will make use
of specialised 3rd party Lab facilities. However in the future, the benefits of having these
facilities as part of the JTL are being assessed – especially with regard to End-to-End
system testing. This assessment may result in physical products being maintained as part
of the JTL facilities.
4.11.3
Product Level
Although it is not possible to ensure an exhaustive product breakdown structure until the
System Design is in place, it is possible to generate a close approximation, in ‘candidate’
terms as listed below:
















Document1
Version 1.0
TMS Servers
TMS Workplaces
Other TMS products and relevant simulators.
IXLs
Track Vacancy Proving equipment (e.g. axle-counters and evaluator units)
Object Controller equipment
Point Machine equipment
Level Crossing equipment
Marker board representation
RBCs
Balises
HHTs
JRUs
KMS products (KMC, download / upload tools,)
Clocks (driven by System Time-Source or GPS signal as agreed with JTL
members)
Peripheral computers as needed. E.g.:
- Simulators (Track, Train, Weather Conditions, Driver Reaction, etc.)
Page 32 of 37


4.11.4
- Communication Gateways and Routers
- Test Campaign Administration
- Data Logging
- Scenario Composition and Playback parameters
- Alarm Management
- Application Data Programming / Analysis tools
- Etc.
ETCS Onboard products (Including the EVC, DMI, JRU, STM –with trackside
ATC simulator, and Odometry products)
GSM-R and GPRS products and relevant simulators (including BTS, BSC, MSC,
mobile devices and corresponding SIM cards)
LRU level
For completeness and also because the JTL can be used to demonstrate maintainability
design, maintenance tools and methodology proposed by the suppliers, there is an
opportunity to agree the approach to handling the ‘Line Replaceable Units’ (LRU)s
pertaining to a specific product.
Customer expectation is that this will be jointly agreed with the Suppliers during the Joint
design Phase. This will create an LRU philosophy that is feasible for Fjernbane East,
Fjernbane West and Onboard operations. The philosophy can then be justified on the
basis of system RAM targets as well as first line maintenance infrastructure.
4.12
Types of Tests
Essentially, the JTL is all about mitigating the risk of putting flawed products, processes,
subsystems and their interfaces into operation. Doing so, can lead to a negative and
potentially fatal impact on the running railway. The mitigation is based on a coordinated
and progressively inclusive, and hence complex series of test campaigns.
The results of the testing vouch for the maturity and effectiveness of the solutions
provided in order to offer fully-functional, safe and seamless operation.
Testing at the JTL is expected to follow on from the testing conducted and proven at the
supplier’s premises. This is up to and including the formal witnessing of the Factory
Acceptance Testing (FAT) campaign.
However, with Customer agreement, the JTL offers the flexibility to emulate FAT
campaigns within Denmark and hence local to the application environment for emergent
supplier solutions. Naturally, such tests will require the same level of detailed diligence
as those completed on Supplier premises – including validating product serial numbers
for example.
The Customer recognises the mutual advantage of using the JTL for FAT level testing
with respect to successful preparations for joint FAT testing, (i.e. solutions integrated
Document1
Version 1.0
Page 33 of 37
with the other supplier’s solutions), site Integration Testing as well as Site Acceptance
Testing.
Furthermore, the JTL offers cost, safety as well as time efficiencies to the JTL members
by allowing the minimisation of lineside testing prior to Early deployment and Rollout
phases.
With this in mind, the customer expects mutual advantages to be gained by the JTL
members from using the JTL facilities.
As per classic testing, test campaigns using the JTL resources can only progress if
approved and comprehensive test documentation (including plans, methodologies as well
as test cases) are in place. The customer expects close collaboration between JTL
members and their respective Quality Assurance departments to achieve this aim.
Post System-Commissioning, when the JTL will move to the next phase of its lifecycle,
the approach and discipline of using test-cases to specify various test scenarios, based on
preconditions, actions and expected post-conditions will continue.
The customer expects the JTL members will adhere to management processes to ensure
this level of integrity continues to be the norm in using the JTL resources.
In parallel, test campaigns, (like the hardware, software and interfaces that are the
subjects of the testing) will be subject to strict configuration management practise. By
doing so, JTL members can benefit not only from scenario based testing but also play
those scenarios according to different software and hardware evolutions.
The customer expects the following set of high level test themes to be exercised within
the JTL environment in order to gain confidence that the proposed solutions are ready to
install and apply within the operational environment.
1. End to End Functional Testing – making use of both “black box” and “white
box” levels of testing.
2. Performance Testing (Latency and Delay at System level as well as product
performance speeds).
3. Interface testing with External interfaces.
4. East / West Interface Testing (RBC Handover, KMS, IXL synching, TMS
messages).
5. Technology Switchover Testing to cover CSD to PSD modes and back again
(This also needs close collaboration with the Trainborne Subsystem).
6. Integration test support for LRUs into Products.
7. Integrating Products into Subsystems - including Interfaces.
8. Integrating Subsystem into the Overall System : (Note, once this is done, reverts
to integrating Products into Subsystems).
9. Hardware and Software Integration.
10. Application Data Testing.
11. Interoperability testing.
12. Backward Compatibility testing.
13. Regression Testing.
14. Soak / Durability Testing.
Document1
Version 1.0
Page 34 of 37
15. Representative EMC testing (e.g. using detectors and meters to assess shielding
and interference-proofing at product level).
16. Stress / Robustness Testing - including Dimensioning testing of the RBC, IXL,
and Communications network.
17. The verification, validation and (if needed), adjustment of the new TMS
processes.
18. Anomaly Diagnosis and Testing.
19. Alarm effectiveness Testing.
20. Pre SAT Readiness Testing.
4.13
Type of Demonstrations
Aside from testing, the JTL is foreseen to be used to showcase the end-to-end
functionality and performance of the overall System. To do this, it is not strictly
necessary to launch a test-scenario. Rather it is sufficient to replay a previously tested
(and successful) scenario from the playback simulator. In fact, (depending on the
audience), demonstrations may be more relevant. Hence the differentiation placed
between using the JTL resources either for testing, or for demonstration.
However, that is not to say that JTL demonstrations do not require a management process
that is in place to capture any anomalies or abnormal system behaviour that may
potentially occur.
Just as for testing activities, anomalies will require investigation and rectification in
accordance with change and configuration management processes.
The following list records the type of demonstrations possible at the JTL:
1. Current System Baseline Demonstration –
2. Ergonomics and Usability demonstration
a. e.g. for HMIs, test, programming, diagnostic and maintenance tools
3. Demonstration of BDK owned Interface Protocols and details.
4. Time-Source Synchronisation Demonstration (Across East & West)
5. Accelerated Time Demonstrations (Scenarios speeded up / fast-forwarded, to
view predicted results).
6. Installation & Test Readiness Methodology demonstration
7. Product Maintainability Demo
8. Shadow mode Monitoring (i.e. Observing the System Behaviour on the available
MMIs in the “Central Control Area”).
9. Playback of Operational Scenarios
10. Stimulation by Event Case or by Timing Case
11. Playback of Maintenance / Fault / Legal-Data Scenarios
12. Degradation and Recovery Methodology Demonstration
a. Fall back Scenarios standardisation
13. Handover / Takeover of “Lot Not Awarded” readiness demonstration
Document1
Version 1.0
Page 35 of 37
5
Conclusion
Though the understanding that the JTL is an integral part of the Fjernbane Infrastructure
and Onboard test strategy, providing clear and beneficial outcomes, (such as
demonstrating the end-to-end functionality of the Overall System), there remains the need
to actually establish the JTL. This paper, by considering a high level delivery schedule
has identified the 3rd quarter of 2012 as the target date for commissioning the JTL.
This document also shows that a coordinated philosophy on the primary and secondary
objectives of the JTL need to be further developed with input from the System Suppliers.
The JTL can fulfil act as a Denmark based centre of excellence for the integration testing
and demonstration of interoperability between ETCS, GSM-R, GPRS systems as well as
more specialised systems such as the TMS and the On-line KMS. Remote
interconnection (via the BDK FTN), with other test labs, be they from ERTMS equipment
suppliers or with other specialised labs - also becomes a distinct possibility for the JTL
scope.
The JTL therefore encompasses a broader view of testing than just “interoperability” of
ETCS systems. This is because it also includes overall functionality of other systems as
named in the paragraph above, but also incorporates the verification and validation of the
TMS and the applicable operational rules of the railway.
Indeed, one broad range concept yet to be explored and evaluated, is of the JTL also
providing a home for the KMC / CA needed to manage the cryptographic keys required
for both Danish and Foreign train authentication in order to run on Danish ETCS
infrastructure.
To achieve the JTL objectives it is necessary to mobilise both Customer and Supplier
resources within a management processes framework to plan, design, build and maintain
the JTL and to create the supporting documentation. Third party stakeholders are also
involved.
Provisional figures have been offered to illustrate the practicalities of the JTL, for
example quoting anticipated floor size for the lab and the various uses of space
anticipated.
The JTL will span both the project and the operational period of the Banedanmark
Signalling Programme. This crossover leads to the recognition that the JTL has an
independent lifecycle with many events occurring within it that require further
management processes. It is also recognised that a dedicated team needs to be recruited
and allocated to manage the JTL.
The efficiencies that can be drawn from the JTL with respect to time, cost and overall risk
reduction to the Fjernbane projects (Infrastructure and Onboard) suggest that this work
stream is of urgent value and provides opportunity for close cooperation between the
Customer and potential Suppliers leading up to the BAFO period and onwards.
Section 4.5 of this document has shown the need for close collaboration between the JTL
members and each party will need to provide a range of the identified skills and
Document1
Version 1.0
Page 36 of 37
competencies to deliver their contribution to the JTL. Having the JTL members being
collocated within the Lab, as soon as the JTL is commissioned, suggests that there are
also benefits to be gained for the successful completion of the Joint Design phase of the
Fjernbane projects.
Comparisons with current practise, largely inspired by the Cedex lab of Spain and
experience of other test laboratories, have inspired a collection of preconditions and
apportionment of roles between the Customer, the Suppliers and relevant 3rd parties.
The JTL preconditions and apportionment of roles also created the context for the
subsequent requirements for delivering the JTL.
As a next step, the contents of this concept paper (including the outlines for Supplier
responsibilities, System requirements and statements dealing with JTL practicalities), will
be shared with prospective suppliers and hence further developed, elaborated and
therefore integrated into the BAFO material for the Fjernbane Project Tenders.
Document1
Version 1.0
Page 37 of 37