PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
EUROPEAN RAILWAY AGENCY
ETCS B3 Release 2
PROJECT PLAN
Document ID: ERTMS Unit
Document type:
Project Plan
Classification:
Origin:
ERA
Activity Based Item:
07.01 Change Control
Management for
ETCS and GSM-R
Unit:
ERTMS
Sector: N/A
Name
Position
Date
Signature
Elaborated by
Olivier GEMINE
Alain HOUGARDY
Oscar REBOLLO BRAVO
Project Officers
Extranet
Validated by
Pio GUIDO
Approved by
Pio GUIDO
Head of ERTMS Unit
Head of ERTMS Unit
Document history
Version
0.1
0.2
1.0
1.1
Date
25/07/2014
07/08/2014
14/08/2014
12/09/2014
Comments
First Draft
Accepted comments from ERA internal review
Delivery to sector organisations
Inclusion of comments received from EC (Mrs Judit Sandor)
Update after EECT in September 2014
Page 1 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
1.2
22/10/2014
1.3
1.4
1.5
1.6
1.7
23/10/2014
10/11/2014
10/12/2014
19/01/2014
17/02/2015
1.8
1.9
12/03/2015
16/04/2015
1.10
1.11
1.12
1.13
23/04/2015
08/05/2015
19/05/2015
11/06/2015
Update after EECT in October 2014
Inclusion of ERA Scenario 2
ERA Internal Review
Update according to discussion on RISC meeting number 71
Update after EECT in December 2014
Update after EECT meeting in January 2015
Update after EECT meeting in February 2015 and feedback from
RISC number 72
Inclusion of section 7.4
Update after EECT meeting in March 2015
Update after dedicated meeting on ATO (20/03/15)
Update after EECT meeting in March 2015
Update after CG meeting (23/04/2015)
Update of the action lists
Update after EECT meeting in May 2015
Update after CG meeting (28/05/2015)
Update after EECT meeting nr 10. (June 2015)
Page 2 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
1.
CONTENTS
1. CONTENTS ..................................................................................................... 3
1.1.
1.2.
List of Figures .................................................................................................. 3
List of Tables ................................................................................................... 3
2. REFERENCES, DEFINITIONS AND ABBREVIATIONS ............................................. 5
2.1.
2.2.
Reference Documents...................................................................................... 5
Definitions and Abbreviations ........................................................................... 5
2.2.1.
2.2.2.
Standard Terms and Abbreviations ............................................................................. 5
Specific Terms and Abbreviations ............................................................................... 5
3. PROJECT DEFINITION ...................................................................................... 7
3.1.
3.2.
3.3.
3.4.
3.5.
Purpose and Scope .......................................................................................... 7
Objectives .................................................................................................... 11
Customer ..................................................................................................... 11
Deliverables .................................................................................................. 11
Project Workload .......................................................................................... 12
4. PROJECT ORGANISATION .............................................................................. 13
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
Project Team ................................................................................................ 13
Other Working Groups ................................................................................... 13
Roles and Responsibilities .............................................................................. 15
Structure ...................................................................................................... 16
Monitoring and control .................................................................................. 17
Communication Plan...................................................................................... 17
5. PROJECT TIME PLAN ..................................................................................... 19
6. PROJECT RISKS ............................................................................................. 21
7. PROGRESS REPORT (MARCH 2015) ................................................................ 22
7.1.
7.2.
7.3.
7.4.
1.1.
Change Request Progress ............................................................................... 22
Project Workload Progress ............................................................................. 22
List of open actions........................................................................................ 23
List of agreed solutions .................................................................................. 34
List of Figures
Figure 1: Project structure. ............................................................................................................. 17
Figure 2: Change Request Progress (March 2015). ............................................................................ 22
Figure 3: CR Workload Progress (March 2015). ................................................................................. 22
1.2.
Table 1 :
Table 2 :
Table 3 :
Table 4 :
Table 5 :
List of Tables
Table of Reference Documents ............................................................................................ 5
Table of Terms ................................................................................................................... 5
Table of Abbreviations ........................................................................................................ 5
List of CRs for the B3 release 2 ............................................................................................ 8
Project deliverables .......................................................................................................... 11
Page 3 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Table 5 : Project workload .............................................................................................................. 12
Table 7 : EECT members ................................................................................................................. 13
Table 8 : Supporting Groups ........................................................................................................... 14
Table 9 : Responsibility of each CR for the next B3 release ................................................................ 15
Table 10 : Communication plan ...................................................................................................... 18
Table 11 : Time plan ...................................................................................................................... 19
Table 12 : Project risks ................................................................................................................... 21
Table 13 : List of actions from CR assessment .................................................................................. 23
Table 14 : List of actions from CR resolution .................................................................................... 24
Page 4 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
2.
REFERENCES, DEFINITIONS AND ABBREVIATIONS
2.1.
Reference Documents
Table 1 : Table of Reference Documents
[Ref. N°]
Title
Reference
[1] Management of ERTMS specifications in the context of an
ERTMS breakthrough program
[2] ERTMS Change Control Management
08/57-DV73
ERA_ERTMS_0001
Version
EN01
(27/05/2014)
2.0
(03/06/2010)
[3] ETCS System Version Management
Subset-104
3.1.0
(29/02/2012)
[4] Memorandum of Understanding between the EC, ERA an the
European Rail Sector Associations (CER-UIC-UNIFE-EIM-GSM-R IG
and ERFA) concerning the strenghthening of the cooperation fro
the management of ERTMS
MoU 2012
2012
2.2.
Definitions and Abbreviations
2.2.1.
Standard Terms and Abbreviations
The general terms and abbreviations used in the present document can be found in a standard
dictionary. Furthermore, a glossary of railway terms that focuses primarily on safety and
interoperability terminology, but also on other areas that the Agency can use in its day-to-day
activities as well as in its Workgroups for the development of future publications, is available on the
Agency
website
(http://www.era.europa.eu/Document-Register/Pages/Glossary-of-railwayterms.aspx).
Specific terms and abbreviations are defined in the section below.
2.2.2.
Specific Terms and Abbreviations
This section defines the specific terms and abbreviations that are used frequently in the present
document.
Table 2 : Table of Terms
Term
Definition
Agency
The European Railway Agency (ERA) such as established by the Regulation (EC) No 881/2004
of the European Parliament and of the Council of 29 April 2004 establishing a European
railway agency, as last amended by Regulation (EC) No 1335/2008.
Table 3 : Table of Abbreviations
Abbreviation
Meaning
BCA
Baseline Compatibility Analysis
CCS
Control Command and Signalling
CR
Change Request
EECT
ERA Extended Core Team
Page 5 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Table 3 : Table of Abbreviations
Abbreviation
Meaning
ERA
European Railway Agency
MR
Maintenance Release
NTR
National Technical Rule
PM
Project Manager
RISC
Railway Interoperability and Safety Committee
ToR
Terms of Reference
TSI
Technical Specification for Interoperability
Page 6 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
3.
PROJECT DEFINITION
3.1.
Purpose and Scope
The ETCS Baseline 3 was functionally defined for the first time in the Commission Decision
2012/696/EU. A first Maintenance Release (MR1) according to the ERTMS Change Control
Management [2] was developed by the Agency together with the Sector resulting in the
Commission Decision (EU) 2015/14 that modified the Annex A of the Technical Specifications for
Interoperability of the Control Command and Signalling (TSI CCS) subsystem.
The project consists in the definition of the next release of the ETCS Baseline 3, so called "ETCS
Baseline 3 Release 2" and of the corresponding Agency’s Recommendation for the update of the
the Annex A of the TSI CCS.
Key principles for the methodology, scope and timing of such activity are contained in the
document [1].
All request for modifications to the ETCS specifications are recorded and managed via the CR
database maintained by the Agency (ERA CR Database). At present there are more than a hundred
CRs in the database to be examined.
ERA in collaboration with the sector (ERTMS UG and Unisig) has carried out an assessment of every
CR stored in the ERA CR Database. The objective is to define the CR list that will be incorporated to
the ETCS specifications in the B3 Release 2. For every CR, the criticality (error)/benefit
(enhancement), the workload and the impact on the TSI CCS specs have been scored in a
qualitative way according to the following scoring: 1-negligible, 2-low, 3-medium, 4-high and 5outstanding.
The CR list has been discussed for the CR already known and stored in the ERA CR Database, during
the RISC meeting number 71 and 72. The RISC has confirmed that the priority is compatibility with
B3 MR1.
Therefore the list has been elaborated according to the following criteria:

Only error correction and enhancement CRs which are fully compatible (both
forwards and backwards) with B3 MR1 are accepted in this basket.

Error CRs with criticality scoring > 1 are accepted in this basket.

Error CRs with workload scoring = 1 (so called quick wins) are accepted in this basket.

“Compatible” enhancements listed in the MoU 2012 are taken into account (packetswitched, ATO,..).

“Compatible” enhancements with a workload assessed by ERA < 3 are accepted in this
basket

“Compatible” enhancements with a unanimously agreed high benefit (>3) are
accepted in this basket.
The inclusion of new submitted CR will depend on the assessment and a possible agreement during
the EECT meetings but every new enhancement CR will always have to provide a clear substantial
justification (why?) and an impact assessment ( and value for the EU system).
Page 7 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
The list also takes into account that the project duration is 16 months (from September 2014 till
December 2015) and the workload that can be processed by that time. The Agency estimates that
the maximum qualitative workload units1 that can be dealt realistically in the best case is about 200
and that would require a high improvement in the organization of the work with the Sector,
compared with previous experiences.
The current list is based on error correction for compatible errors and introduction of new
compatible enhancement committed in the MoU signed by the Agency in 2012 [4] or with a high
benefit and low workload. The aim is to protect the investments in Baseline 3 onboard systems by
RU and leasing companies, and is in line with the principles stated in [1]. The list of CRs includes
also the high-value enhancements recognized in the ERTMS MoU of 2012, to be developed as
compatible options (“Y change”).
It is also important to remark that there is likely some hidden workload that could arise during the
CR resolution, for instance, new errors detected that could need an urgent solution or cover
Change Requests for sub-documents (other Subsets).
As a reference, for the MR1 26 CRs were processed in 15 months, considering the worst case i.e. 5
workload units per CR would mean 130 units (5x26).
This plan is a living document: it will be updated to take account the final decision on the scope and
content of B3 Release 2.
As agreed with the sector in the Control Group (see minutes CG 81), the EECT WG shall carry out a
compatibility analysis of coexisting Baselines. In particular all these CRs will be analysed for
potential compatibility problems within Baseline 2, i.e. between Baseline 2 on-board and trackside.
This project plan proposes dedicated days in the EECT meetings for this compatibility analysis, the
so called Baseline Compatibility Analysis applying the principles of the System Version
Management [3].
Finally, there is also a delivery preparation activity consisting in implementing the agreed CR
solutions in the corresponding subsets/documents plus the review from the other partners.
Table 4 : List of CRs for the B3 release 2
Change
Request
Title
(1-5)
Impact on
TSI CCS
specs (1-5)
Error
3
2
Enhancement
2
2
Error
3
2
Enhancement
5
5
Type
Workload
0239
Train data on TIU
0539
Set speed indication for driver
0740
Unclear requirements concerning functions active in
L2/L3 only
0741
Packet data transmission for ETCS
0852
Definition of level 2/3 area and level transition border
Error
4
4
0933
Storing of RBC contact information
Error
3
2
1014
Duplicated balises ambiguities
Error
2
3
1 From 1 to 5 workload units are allocated to each CR
Page 8 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Table 4 : List of CRs for the B3 release 2
Change
Request
Title
Type
(1-5)
Impact on
TSI CCS
specs (1-5)
Workload
1021
Brake command revocation/acknowledgement issues
Error
3
3
1033
Disable Start in SR if no safe connection
Error
2
2
1078
Display of indication marker
Error
4
3
1084
Target speed masking
Enhancement
4
3
1086
Unknown L1 LRBG reported to RBC
Enhancement
3
2
1087
Manual network selection
Enhancement
4
3
1089
Ack for text messages in NL mode
Error
1
1
Enhancement
4
1
Error
3
2
Enhancement
2
2
Error
2
2
Error
3
3
Error
2
2
1091 (*)
Insufficient driver information in OS
1094
Unclear stop conditions for display of some DMI objects
1107
Status planning information on the DMI in FS mode
1116
1117
1122
Reception of an order to establish a communication
session with an RBC while a communication session is
under termination with the same RBC
Reception of an order to terminate a communication
session while session is being established
Communication session establishment to report change
to SL mode
1125
Clarification of human role in ETCS safety analysis
Error
3
3
1128
Passing Level 0 / Level NTC border in PT mode
Error
3
2
1129
DMI indication of level announcement in SB
Error
2
2
1152
Avoid increase of permitted speed and target distance
Error
4
3
1163
Train interface – Track conditions related outputs to be
harmonized
Error
3
3
1164
Ambiguity in assignment of coordinate system
Error
1
1
1165
Release speed after accepted conditional emergency
stop
Error
2
2
1167
Juridical data for the equivalent brake build-up time
Error
2
2
1169
Ambiguity about the variable L_STMPACKET in juridical
data STM INFORMATION
Error
2
2
1172
Problems related to level crossing supervision
Error
3
3
1180
Guard rails and cables in the vicinity of balises
Error
4
3
Missing requirement for the number of communication
sessions an OBU must be capable to handle
simultaneously
Error
1
1
1187
Indication marker inconsistency
Error
4
3
1188
Balises in Multi-Rail Track
Error
3
3
1190
UES text message end condition
1184 (*)
Enhancement
3
2
Ambiguity regarding the temporary EOAs and SvLs
Error
3
3
1220
Level transition order in SH and driver acknowledgment
Error
2
2
1221
Availability of Override and Start buttons
Error
2
2
1222
Inconsistency regarding list of BGs for SH area
Error
1
1
Enhancement
2
1
1197 (*)
1229 (*)
Age requirement for estimated speed
Page 9 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Table 4 : List of CRs for the B3 release 2
Change
Request
Title
(1-5)
Impact on
TSI CCS
specs (1-5)
Error
3
2
Type
Workload
1236
Criteria for Levels in train unclear
1237
KMS evolution
Enhancement
5
5
1238
Automatic Train Operation over ETCS
Enhancement
5
5
1242
Several problems with STM specifications
Error
2
3
1245
Display of ETCS override in level NTC
Error
3
3
Enhancement
4
4
1249 (*)
Problems with pre-indication
1250
Incorrect description in gradient profile
Error
1
1
1254
Session establishment attempts to report mode change
Error
3
3
1255
Error
2
2
Error
2
3
Error
3
3
1265
Impossibility to transmit unknown values in the
message “Additional data”
Inconsistent set of clauses regarding the service brake
interface in SH mode
Issues related to the initiation of a communication
session by an RBC
Miscellaneous editorial findings in B3 MR1
Error
2
1
1266
Classification of SRS requirements
Error
4
3
1273
Impact of UIC 544-1 new version
Error
1
1
1275
Error
4
2
Error
4
3
1278
Eurobalise transmission susceptibility requirements not
linked to interoperability
D7 of SoM procedure is reached while no Mobile
Terminal is registered yet
SUBSET-074 upgrade to Baseline 3 Release 2 (B3R2)
Error
3
3
1279
Inconsistencies between Subset-034, Subset-035 and
Subset-058
Error
3
3
TOTAL
148/133
(*)
130/117
(*)
1260
1262 (*)
1277
(*) This CR will be included in the B3 Release 2 only if it is compatible according to the SS-104 [3], final workload and TSI specs
varies if the CR is IN or OUT of the list
Green shaded lines stands for closed and agreed CR i.e. in status “Analysis Completed” in the ERA
CR Database.
Grey shaded lines stands for rejected, postponed or superseded CR i.e. in status “Rejected”,
"Postponed" or “Superseded” in the ERA CR Database.
White shaded lines stands for CR that is in the next release but the technical discussion to find a
solution has not started yet.
Blue shaded lines stands for CR that will be treated in the next EECT meeting.
For futher information about the agreed solutions for the CR already solved, see section [7.4].
Page 10 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
3.2.
Objectives
The objectives of the project is to provide a technical solution to every Change Request included in
the list of CR that will be incorporated to the relevant technical document/Subset of the ETCS
specification for the next B3 release by end 2015.
The B3 Release 2 shall be compatible with the ETCS Baseline 2.
3.3.
Customer
The main customer of the project will be the European Commission (EC) and the EU Member Sates
because the result of the project will be delivered to the EC as an ERA Recommendation.
3.4.
Deliverables
Though it is difficult to name exactly and in a close manner the number of documents that finally
will be impacted by the Change Request processed, the Agency expects the update of the following
documents in the Annex A of the TSI:
Table 5 : Project deliverables for Annex A update
TSI CCS Annex A Reference
Title
Subset-023
Glossary of terms and Abbreviations
Subset-026
System Requirements Specification
Subset-027
FIS Juridical Recording
ERA_ERTMS_015560
ETCS Driver Machine Interface
Subset-034
Train Interface FIS
Subset-035
Specific Transmission Module FFFIS
Subset-036
FFFIS for Eurobalise
Subset-037
EuroRadio FIS
Subset-039
FIS for the RBC/RBC handover
Subset-040
Subset-041
Dimensioning and Engineering rules
Performance Requirements for Interoperability
Subset-057
STM FFFIS Safe Link Layer
Subset-058
FFFIS STM Application Layer
Subset-059
Performance requirements for STM
Subset-074-2
FFFIS STM Test cases document
Subset-076-7
Scope of the Test Specification
Subset-091
Safety Requirements fo the Technical Interoperability of ETCS in Levels 1 and 2
Besides, the following deliverables are part of the scope of the project though they are not part of
the Annex A CCS TSI:
Page 11 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Table 6 : Other Project deliverables
Deliverable
Title
BCA report
Baseline Compatibility Analysis Final Report
3.5.
Project Workload
The main workload of the project is related to the CR resolution (see Table 4), nevertheless there
are also two other activities that will need to be undertaken by the EECT and that are time and
resources consuming. Namely, the compatibility between baselines assessment and the delivery
preparation.
The Agency considers that the compatibility assessment workload can be estimated at 0,5
workload units per CR to be assessed.
The Agency considers that the delivery preparation workload can be estimated at 0,5 workload
units per CR to be implemented.
The Agency considers that the workoload used to discuss CRs finally rejected, postponed or
superseded have been fully used(i.e. CR 1078, CR 1116, CR 1165, CR 1220 and CR1238).
Table 7 : Project workload
Activity
Workload Units
CR Resolution
148
Compatibility Assessment
26,5
Delivery Preparation
CR
Superseeded/Postponed/Rej
ected
Contingency Workload
Available
TOTAL
26,5
15
0
216
Page 12 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
4.
PROJECT ORGANISATION
4.1.
Project Team
The project team will be organised as an Agency Working Party called ERA Extended Core Team
(EECT), this Working Group (WG) will be composed of experts from the sector organisations and
ERA staff. The Chairmanship and the project management of the WG will be the responsibility of
the Agency.
The scope of the EECT will be to fulfil the roles and responsibilities of the ERA Core Team as well as
the role of a permanent ad-hoc task force as defined in the ERTMS Change Control Management
(see [2], 4.2.4 and 5.2.2.5.1 b).
The EECT WG will be composed of the following members:
Table 8 : EECT members
Item
Organisation
Olivier Gemine
ERA
Alain Hougardy
ERA
Oscar Rebollo Bravo
ERA
Philippe Prieels
Unife (Unisig)
Unisig Expert 1
Unife (Unisig)
Unisig Expert 2
Unife (Unisig)
Rob Dijkman
EIM/CER (ERTMS UG)
Laura Arenas
EIM/CER (ERTMS UG)
Railways Expert 1
EIM/CER (ERTMS UG)
Ron Bailes
CER
E-mail
olivier.gemine@era.europa.eu
Tel
+33 327096538
alain.hougardy@era.europa.eu
+33 327096591
oscar.rebollo@era.europa.eu
+33 327096504
philippe.prieels@transport.alstom.com
rdijkman@ertms.be
larenas@ertms.be
+32 71445253
+32 26635620
+ 32 26739933
Ron.Bailes@atoc.org
ERA staff will not change during the project life time while Unisig and the ERTMS UG will work
rotating two experts at their best convenience according to the agenda proposed by ERA.
The members of the EECT Working Group can have their expenses reimbursed by the Agency,
according to decision n° 21/2008 adopted by the ERA Administrative Board on 28 October 2008.
It will be up to the EECT Working Group to dispatch or to assign specific CRs or tasks to the existing
supporting groups or to create ad-hoc WGs (if necessary).
4.2.
Other Working Groups
The EECT shall be supported by other Working Groups, mainly by the ERTMS UG CR WG and the
Unisig Supergroup. Other WGs, already dealing with specific subsets of the ETCS specifications or
ad-hoc taskforces created to deal with specific topics, shall support the EECT on demand.
Page 13 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
In addition, as some of the CRs can also affect the radio communication system, it is expected to
involve the related WGs.
When a CR or a task is assigned to a supporting WG or an ad-hoc WG, the WG leader shall be
available on request of the EECT. i.e. to discuss by phone or to attend an EECT meeting (if needed).
Though it is difficult to know beforehand which WGs and when they will be needed, the following
table shows the WGs that will be involved based on the list in table 8:
Table 9 : Supporting Groups
Supporting WGs
CRs involvement
EECT meeting
EECT 1 (09-10 Sep 2014)
EECT 2 (07-08 Oct 2014)
EECT 3 (04-05 Nov 2014)
EECT 4 (01-02-03 Dec 2014)
EECT 6 (10-11 Feb 2015)
ERTMS UG / UNISIG EoG WG
0741
EECT 7 (09-10-11 Mar 2015)
EECT 8 (15-16 Apr 2015)
EECT 9 (12-13 May 2015)
EECT 10 (09-10 Jun 2015)
EECT 11 (08-09 Jul 2015)
EECT 12 (08-09 Sep 2015)
EECT 2 (07-08 Oct 2014)
EECT 3 (04-05 Nov 2014)
ERTMS UG / UNISIG ATO WG
1238
EECT 6 (10-11 Feb 2015)
EECT 7 (09-10-11 Mar 2015)
EECT 8 (15-16 Apr 2015)
EECT 3 (04-05 Nov 2014)
EECT 7 (09-10-11 Mar 2015)
EECT 9 (12-13 May 2015)
ERTMS UG / UNISIG Key Management WG
1237
EECT 10 (09-10 Jun 2015)
EECT 11 (08-09 Jul 2015)
EECT 12 (08-09 Sep 2015)
EECT 13 (06-07 Oct 2015)
UNISIG Eurobalise WG
1180, 1188, 1275, 1279
ERA Operational Harmonisation WG
1089, 1094, 1129, 1190
STM WG
1242, 1245, 1278
EECT 3 (04-05 Nov 2014)
EECT 11 (08-09 Jul 2015)
EECT 4 (01-02-03 Dec 2014)
EECT 5 (13-14 January)
EECT 12 (08-09 Sep 2015)
Page 14 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
4.3.
Roles and Responsibilities
Each organisation shall be responsible for the delivery of a set of Change Requests and shall deliver
solution proposals for these CRs, the other two organisations shall review the proposed solutions.
Hereafter the list of CRs with the assignment of responsibilities that will be discussed during the
EECT meetings (see Chapter 5). For the CR with no responsible defined it will be done in due time.
Table 10 : Responsibility of each CR for the next B3 release
Change
Request
Title
Responsible
0239
Train data on TIU
0539
Set speed indication for driver
0740
Unclear requirements concerning functions active in L2/L3 only
0741
Packet data transmission for ETCS
0852
Definition of level 2/3 area and level transition border
UNISIG
0933
Storing of RBC contact information
UNISIG
1014
Duplicated balises ambiguities
UNISIG
1021
Brake command revocation/acknowledgement issues
UNISIG
1033
Disable Start in SR if no safe connection
ERA
1078
Display of indication marker
ERA
1084
Target speed masking
ERA
1086
Unknown L1 LRBG reported to RBC
ERA
1087
Manual network selection
ERA
1089
Ack for text messages in NL mode
ERA
Insufficient driver information in OS
ERA
1094
Unclear stop conditions for display of some DMI objects
ERA
1107
Status planning information on the DMI in FS mode
ERA
1091 (*)
1116
1117
Reception of an order to establish a communication session with an
RBC while a communication session is under termination with the same
RBC
Reception of an order to terminate a communication session while
session is being established
UNISIG
ERTMS UG/ERA
UNISIG
UNISIG/ERTMS UG
UNISIG
UNISIG
1122
Communication session establishment to report change to SL mode
UNISIG
1125
Clarification of human role in ETCS safety analysis
UNISIG
1128
Passing Level 0 / Level NTC border in PT mode
UNISIG
1129
DMI indication of level announcement in SB
ERA
1152
Avoid increase of permitted speed and target distance
ERA
1163
Train interface – Track conditions related outputs to be harmonized
1164
Ambiguity in assignment of coordinate system
ERA
1165
Release speed after accepted conditional emergency stop
ERA
1167
Juridical data for the equivalent brake build-up time
ERA
1169
Ambiguity about the variable L_STMPACKET in juridical data STM
INFORMATION
ERA
UNISIG
Page 15 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Table 10 : Responsibility of each CR for the next B3 release
Change
Request
Title
Responsible
1172
Problems related to level crossing supervision
ERA
1180
Guard rails and cables in the vicinity of balises
UNISIG
1184 (*)
Missing requirement for the number of communication sessions an
OBU must be capable to handle simultaneously
ERA
1187
Indication marker inconsistency
ERA
1188
Balises in Multi-Rail Track
1190
UES text message end condition
ERA
Ambiguity regarding the temporary EOAs and SvLs
ERA
1220
Level transition order in SH and driver acknowledgment
ERA
1221
Availability of Override and Start buttons
ERA
1222
Inconsistency regarding list of BGs for SH area
ERA
Age requirement for estimated speed
ERA
1236
Criteria for Levels in train unclear
ERA
1237
KMS evolution
UNISIG/ERTMS UG
1238
Automatic Train Operation over ETCS
UNISIG/ERTMS UG
1242
Several problems with STM specifications
UNISIG
Display of ETCS override in level NTC
Problems with pre-indication
UNISIG
1250
1254
Incorrect description in gradient profile
Session establishment attempts to report mode change
UNISIG
1255
Impossibility to transmit unknown values in the message “Additional
data”
Inconsistent set of clauses regarding the service brake interface in SH
mode
Issues related to the initiation of a communication session by an RBC
1197 (*)
1229 (*)
1245
1249 (*)
1260
1262 (*)
UNISIG
ERA
UNISIG
ERA
ERA
UNISIG
1265
Miscellaneous editorial findings in B3 MR1
ERA
1266
Classification of SRS requirements
ERA
1273
ERA
UNISIG
1277
Impact of UIC 544-1 new version
Eurobalise transmission susceptibility requirements not linked to
interoperability
D7 of SoM procedure is reached while no Mobile Terminal is registered
yet
1278
SUBSET-074 upgrade to Baseline 3 Release 2 (B3R2)
UNISIG
1279
Inconsistencies between Subset-034, Subset-035 and Subset-058
UNISIG
1275
ERA
(*) This CR will be included in the B3 Release 2 only if it is compatible according to the SS-104 [3]
4.4.
Structure
Page 16 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
CONTROL GROUP
Project Governance
ERA Project
Management
EECT
Project Team
Ad-hoc
Taskforces
Workshops
WG A
WG B
WG C
Figure 1: Project structure.
4.5.
Monitoring and control
The monitoring and control will be established at two levels, the first level shall be at organisation
level. A designated Project Manager of each organisation shall be responsible for the allocation of
the workload within its own organisation and follow the actions allocated.
At a second level i.e. the project level the monitoring and control will be guaranteed by the Agency
Project Manager. In particular, the Agency shall monitor and control:




4.6.
The delivery of the CR solution when they are responsible for the CR solution.
The delivery of the review of the CR solutions when they are not responsible for the CR
solution.
The overall performance of each individual organisation.
The actions allocated to each organisation in the EECT meetings shall be delivered with the
agreed quality and in time.
Communication Plan
The table below presents the communications that will be done during the project lifecycle.
Page 17 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Table 11 : Communication plan
Communication
Description
Frequency
Progress Report
The report will analyse the After each
progress during the period EECT
and, if relevant, in
meeting
comparison with the initial
project plan.
Format
Owner
Recipient /
Attendees
E-mail and
Extranet
ERA
CG Members
EECT Members
Mirror PMs
EC
RISC (via EC)
ERA Website
Specific Progress Reports Requested information
On
demand
Any format ERA
requested
Minutes
Minutes of each EECT
After each
EECT
meeting
E-mail and
Extranet
ERA
ERA CR Database Report
Snapshot of the current
content of the database
The WG leader shall be
available on request of the
EECT
Every
month
On
demand
Extranet
ERA
WG leader availability
request
Attendance ERA
or
conference
call
The requester
(e.g. MoU SC, EC,
…)
CG Members
EECT Members
Mirror PMs
ERA website
EECT members
CG Members
WG Leader
Page 18 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
5.
PROJECT TIME PLAN
The EECT will meet on a two-day basis at ERA premises in Lille according to the following schedule:
Table 12 : Time plan
Meeting
Nr.
Dates
CRs on the Agenda
CRs to be closed during the meeting
1
09-10 Sep
2014
0239, 0539, 0741, 1033, 1086, 1089,
1091, 1107, 1163, 1164, 1165, 1222.
Closed: 0239, 1033, 1089, 1107, 1163, 1164,
1222.
07-08 Oct
2014
04-05 Nov
2014
01-02-03
Dec 2014
0539, 0741, 1084, 1086, 1116, 1117,
1122, 1167, 1169, 1172, 1220, 1238.
0539, 0741, 0933, 1014, 1084, ,1086,
1180, 1188, 1236, 1237, 1238.
0740, 0741, 0852, 0933, 1014, 1084,
1094, 1128, 1129, 1190, 1221 , 1250
0740, 0933, 1084, 1094, 1128, 1129,
1242, 1245
Baseline Compatibility Analysis
0741, 1078, 1084, 1129, 1187, 1238,
1245,
Baseline Compatibility Analysis
Closed: 1117, 1122, 1167, 1169, 1172
Rejected: 1116, 1220
2
3
4
5
13-14 Jan
2015
6
10-11 Feb
2015
7
09-10-11
Mar 2015
0741, 0933, 1078, 1152, 1187, 1237,
1238, 1245, 1255, 1260, 1266
8
15-16 Apr
2015
0239, 0741, 1021, 1087, 1125, 1152,
1184, 1238, 1249, 1265
9
12-13 May
2015
10
09-10 Jun
2015
11
08-09 Jul
2015
12
08-09 Sep
2015
13
14
15
06-07 Oct
2015
03-04 Nov
2015
01-02 Dec
2015
Closed: 0539, 1086, 1180, 1188, 1236.
Closed: 1014, 1190, 1221, 1250
Superdeded: 1165
Closed: 1094, 1128, 1242
Closed: 1129
Closed: 0933, 1245,1255, 1260
Superseded: 1078
Reopened: 0239
Closed: 0239
Reopened: 1107
0741, 1087, 1107, 1125, 1152, 1184,
1187, 1249, 1262, 1265, 1266
Baseline Compatibility Analysis
0741, 0852, 1021, 1084, 1091, 1152,
1184, 1197, 1229, 1237, 1249, 1254,
1262, 1265, 1266
0741, 1021, 1084, 1152, 1184, 1197,
0299*, 1237, 1254, 1262, 1265, 1266,
1275
0740, 0741, 1021, 1237, 1238, 1249,
1265, 1266, 1273, 1275, 1277, 1278,
1279
Baseline Compatibility Analysis
0740, 0741, 1237, 1265, 1266, 1277
Baseline Compatibility Analysis
1084, 1152, 1184, 1197, 0299*,1254, 1262
Documentation preparation
Documentation preparation
Documentation preparation
Documentation preparation
Closed: 1087, 1107, 1125, 1187
Closed: 0852, 1091, 1229
1021, 1249, 1273, 1275, 1278, 1279
Baseline Compatibility Analysis
0740, 0741, 1237, 1265, 1266, 1277
Baseline Compatibility Analysis
*The compatibility of CR1229, which is already closed, is subject to the resolution of the CR 0299.
It shall be taken into account that when a discussion on a particular CR is scheduled on an EECT
meeting, the entity in charge of providing the CR solution or fulfilling an action related to the CR
shall do it in advance of the meeting When the action is related to the delivery of a homework with
a review from other organisations needed, the homework shall be delivered at least two weeks in
Page 19 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
advance of the meeting, When the action does not need a third party review, homework shall be
delivered at least one week in advance of the meeting.
There will be three dedicated meetings to carry out the compatibility analysis. The list of CRs for
the compatibility analysis will be distributed with two months in advance of each dedicated
meeting.
The last two months of the project will be dedicated to the introduction of the CRs solutions into
the Subsets and providing the final documents.
Page 20 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
6.
PROJECT RISKS
Table 13 : Project risks
Description
Likelihood
Not enough human
resources
Low
Staff turnover during the
project
Low
Several workgroups involved
High
Short deadlines
High
A lot of meetings foreseen or
meetings with a lot of people
involved
Medium
Difficulty in gathering the
needed information
Not enough quality or delays
in the activities delegated to
other WGs
Political/strategic
implications of the project
Low
Medium
High
Impact
Risk level Mitigating Actions
Careful distribution of activities taking
into account skills and competences
of the different project team
Medium Medium
members; continuous control by
Project Manager looking for
effectiveness
Adequate knowledge management
and hand over of tasks; development
High
Medium
of detailed progress reports with a
clear status of the project, risks,
issues arising, etc.
Control by Project Manager ensuring
adequate coordination and
communication; establishment of
clear responsibilities and decision
making process; planning and
Medium
High
preparation of meetings with enough
time in advance; development of a
communication plan, if needed;
adequate control and dissemination
of reference documents and
developed documents
Detailed project plan; continuous
monitoring and control by Project
High
High
Manager; including additional support
staff if possible
Medium Medium
Adequate planning of dates and
resources needed
Analysis of the possible channels to
gather the information and, as
needed, adequate preparation in
Low
Medium
advance of checklists, etc.;
identification of adequate
interlocutors among the stakeholders
A detailed planning in cooperation
Medium Medium with the WG leader; adequate control
by Project Manager
Involvement of the Control Group on
High
High
idenfied implications
For the time being, the main risk detected is "Short deadlines" due to the project delay
accumulated (51,4 % achived on 62,5% of time consumed). As mitigation measures clear actions
and deadlines have assigned to each stakeholder, besides 3 days meetings could be envisaged for
the September and October meeting.
Page 21 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
7.
PROGRESS REPORT (June 2015)
7.1.
Change Request Progress
The following figure reports on the progress done on the CR resolution:
Figure 2: Change Request Progress (June 2015).
7.2.
Project Workload Progress
The following figure reports on the progress done on the total workload for the project:
Figure 3: CR Workload Progress (June 2015).
Page 22 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
7.3.
List of actions
Table 14 : List of actions from CR assessment
Action
#
CR
08.01
1267
08.02
1274
08.03
1275
08.04
1277
08.05
1279
08.06
Headline
Action
Maintaining a
08.01: to update the problem
communication
description focussing on the deletion of
session when the
RBC data when changing the radio
RBC ID/Phone
network (step D) and cleaning the last
number is
paragraph accordingly.
invalidated
Problem to compare
locations in the
08.02: to score and assess the
absence of linking
compatibility
information
Eurobalise
transmission
susceptibility
08.03: to score and assess the
requirements not
compatibility
linked to
interoperability
D7 of SoM
procedure is
08.04: to score and assess the
reached while no
compatibility
Mobile Terminal is
registered yet
Inconsistencies
between Subset08.05: to score and assess the
034, Subset-035 and
compatibility
Subset-058
08.06: to cross-check with UIC the
Use of IPv4 or IPv6
relevance of this CR
Responsi
ble
Deadline
U
05/05/15
closed
All
05/05/15
closed
All
05/05/15
closed
All
05/05/15
closed
EUG
05/05/15
closed
EUG
05/05/15
closed
Red shaded lines stands for actions not fulfilled on time or with insufficient quality.
Page 23 of 62
Status
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Table 15 : List of actions from CR resolution
Action
#
CR
Headline
Brake command
1021 revocation/acknowl
edgement issues
06.10
06.12
06.13
07.09
1238
1238
Automatic Train
Operation over ETCS
Automatic Train
Operation over ETCS
Action
Responsi
ble
HW
expecte
d by
HW
review
expected
by
To provide a position for item
2 (operational aspects)
EUG/CER
02/06/15
N/A
on-going
To reconsider how ATO
messages should be dealt
within the DMI (permanent
display or current text
messages management)
EUG/U
08/04/15
N/A
closed
EUG
N/A
(answer
available,
see mail
AM 3rd
March)
N/A
closed
N/A
closed
N/A
closed
To reconsider the table 6
proposed and the need to
display outside the FS mode
1238
Automatic Train
Operation over ETCS
To confirm if all failures shall
be reported to the driver also
in another modes than FS
EUG
N/A
(answer
available,
see mail
AM 3rd
March)
0741
Packet data
transmission for
ETCS
To assess the impact on Ss038/SUBSET-114 of such
proposal to manage the
transmission mode together
with the authentication keys.
U
08/04/15
Status
Page 24 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Table 15 : List of actions from CR resolution
Action
#
CR
Headline
Action
Responsi
ble
HW
expecte
d by
HW
review
expected
by
07.09b
0741
Packet data
transmission for
ETCS
To check the above principles
(transmission mode with keys,
no manual CS fallback).
EUG
08/04/15
N/A
on-going
07.10
933
Storing of RBC
contact information
To check if CR1261 can be
superseded
U
08/04/15
N/A
closed
EUG
08/04/15
N/A
closed
U
02/06/15
N/A
closed
07.11
1152
Avoid increase of
permitted speed
and target distance
To reconsider if the "never
increase" generalised principle
can be revoked for the speed
and also if this existing
principle can also be removed
when the SB feedback function
is active
07.11b
1237
KMS evolution
To assess the EUG proposal for
KMAC triggering events
Status
Page 25 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Table 15 : List of actions from CR resolution
Action
#
CR
Headline
Action
Responsi
ble
HW
expecte
d by
HW
review
expected
by
Status
ALL
08/04/15
N/A
closed
07.11c
1238
Automatic Train
Operation over ETCS
To provide a position on the
architecture (FFFIS or internal
function), and in case it is an
internal function whether it
should be mandatory or
optional
07.12
1237
KMS evolution
To deliver the FFFIS on-line key
management document.
U
26/05/15
02/06/15
closed
07.12b
1237
KMS evolution
deliver these updated
documents (FRS, ORS and
Strategy document)
EUG
03/04/15
02/06/15
(U only)
closed
07.12c
1238
Automatic Train
Operation over ETCS
To provide an update of the
document “ATO impact on
ETCS”
U
08/04/15
N/A
closed
Page 26 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Table 15 : List of actions from CR resolution
Action
#
CR
Headline
Action
07.13
Automatic Train
1238
Operation over ETCS
To analyse/find commonalities
in the possible additional data
for ATO
07.14
0239
to deliver an updated solution
Train data on TIU
07.15
1238
Automatic Train
Operation over ETCS
07.16
1238
Automatic Train
Operation over ETCS
To assess SRS tables 4.5.2 and
4.7.2 with regards to the AD
mode (existing
functions/Driver’s I/O and
possible new ones).
To provide a new SUBSET-125
version
Responsi
ble
HW
expecte
d by
HW
review
expected
by
Status
U
08/04/15
ERA
01/04/15
08/04/15
closed
U
28/04/15
N/A
closed
U
14/04/15
N/A
closed
N/A
Page 27 of 62
closed
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Table 15 : List of actions from CR resolution
Action
#
CR
Headline
Action
Responsi
ble
HW
expecte
d by
HW
review
expected
by
Status
To report to the CG that U
does not want to carry on with
such CR with operational
impact without a consolidated
sector position.
ERA
23/04/15
N/A
closed
08.07
Brake command
1021 revocation/acknowl
edgement issues
08.08
1087
Manual network
selection
To redraft the solution
proposal.
ERA
28/04/15
05/05/15
delayed (U
review)
08.09
1125
Clarification of
human role in ETCS
safety analysis
To answer the ERA comment
(14/04/15)
U
04/05/15
N/A
closed
08.10
1152
Avoid increase of
permitted speed
and target distance
To resume the solution
proposal according to the
above.
ERA
05/05/15
N/A
closed
Page 28 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Table 15 : List of actions from CR resolution
Responsi
ble
HW
expecte
d by
HW
review
expected
by
08.11
Problems with preTo check with one of the
1249
indication, Display of
persons who designed the
,
indication marker, original DMI concept, in which
1187
Status planning
no pre-indication existed, why
and
information on the
the planning info was
1107
DMI in FS mode
considered as sufficient.
EUG
05/05/15
N/A
closed
08.12
Problems with pre1249
indication, Display of
,
indication marker,
1187
Status planning
and
information on the
1107
DMI in FS mode
To complete the railways
round table, focussing on the
relevancy/need to add an
audible warning before the
Indication marker reaches the
bottom of the planning info
EUG
05/05/15
N/A
closed
08.13
Problems with pre1249
indication, Display of
,
To consider the addition of a
indication marker,
1187
target speed indication on the
Status planning
and
planning info
information on the
1107
DMI in FS mode
ERA
05/05/15
N/A
closed
08.14
To perform a detailed review
of the ERA solution proposal
Problems with pre1249
01/04/15, together with the
indication, Display of
,
CR1187 and 1107. Justification:
indication marker,
1187
the addition of an audible
Status planning
and
warning and/or target speed
information on the
1107
on the planning info will not
DMI in FS mode
impact the current content of
the solution
U
05/05/15
N/A
closed
08.15
0741
EUG
05/05/15
N/A
closed
Action
#
CR
Headline
Packet data
transmission for
ETCS
Action
To reconsider their position in
the light of the above
discussion
Status
Page 29 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Table 15 : List of actions from CR resolution
CR
Headline
Action
Responsi
ble
HW
expecte
d by
HW
review
expected
by
0741
Packet data
transmission for
ETCS
(follow-up of action 07.09): To
develop the announced use
cases in the light of the above
discussion
U
26/05/15
N/A
closed
0741
Packet data
transmission for
ETCS
To review the new EUG ETCS
over GPRS papers “Comparison
of Solutions for selection of
Radio Bearer Service - PS or CS
All
02/06/15
N/A
ongoingclosed
09.02
1249
Problems with preindication
to pre-assess the ERA
suggestions for the target
speed indication on the
planning info
EUG
02/06/15
N/A
on-going
09.03
1152
Avoid increase of
permitted speed
and target distance
to review the new EUG
additional input delivered
during the meeting
ERA/U
02/06/15
N/A
ongoingclosed
09.04
Issues related to the
To provide a first complete
initiation of a
solution proposal including the
1262
communication
impact on all annex A
session by an RBC
documents
U
26/05/15
02/06/15
on-going
closed
09.05
1266
Classification of SRS
requirements
To provide the review of the
chapters 1,2,5,6,7 and 8
U
30/06/15
N/A
on-going
09.06
933
Baseline
Compatibility
Analysis
To check the mitigation
measure proposed by U in B3
MR1
EUG
01/09/15
N/A
on-going
Action
#
08.16
09.01
Status
Page 30 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Table 15 : List of actions from CR resolution
Action
#
CR
Headline
Action
Responsi
ble
HW
expecte
d by
HW
review
expected
by
09.07
1128
Baseline
Compatibility
Analysis
To answer Q4 in B3 MR1
Maintenance for CR 1128
U
01/09/15
N/A
on-going
09.08
-
Baseline
Compatibility
Analysis
To answer the CRs highlighted
in blue in the tab “B2 (230d)
maintenance”
U
01/09/15
N/A
on-going
To update the problem
description for CR 1197
U
02/06/15
N/A
ongoingclosed
Packet data
transmission for
ETCS
To check with UIC whether
harmonised IP addressing and
network interconnection is
envisaged
ERA
01/07/15
N/A
on-going
Packet data
transmission for
ETCS
To double check with telecom
experts whether allocating a
unique IP address to the CS
RBC’s is not creating any issue
or whether it would be
sufficient to use the default IP
returned from the DNS query
indicating that the RBC is not
found
All
01/07/15
N/A
on-going
09.09
10.01
10.02
Ambiguity regarding
1197 the temporary EOAs
and SvLs
0741
0741
Status
Page 31 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Table 15 : List of actions from CR resolution
Action
#
10.03
10.04
Headline
Action
Responsi
ble
HW
expecte
d by
HW
review
expected
by
0741
Packet data
transmission for
ETCS
To check whether Euroradio
can select the stack to be used
(PS or CS) for each connection
request only on the basis of
the on-board table entry
stored at the time of the
request (i.e. keep Euroradio
not knowing the notion of
ETCS applicative
communication session),
without any adverse effect like
a double CS and PS connection
with the same RBC?
U
01/07/15
N/A
on-going
0741
Packet data
transmission for
ETCS
Should the “use short number”
selection by the driver be
inhibited in case the
connection set up with a PS
RBC has failed?
EUG
24/06/15
01/07/15
on-going
EUG
24/06/15
01/07/15
on-going
CR
Status
10.05
0741
Packet data
transmission for
ETCS
To wrap up all the decisions
made in the previous meetings
and to assemble them in a
single paper enclosing the
solution 5 for the selection of
the transmission mode
10.06
0852
Definition of level
2/3 area and level
transition border
To check whether CR 1256 can
be superseded by CR 852
solution
U
01/07/15
N/A
on-going
10.07
1084
Target speed
masking
To investigate the two U
concerns on the ERA solution
proposal
ERA
01/07/15
N/A
on-going
1152
Avoid increase of
permitted speed
and target distance
To provide an updated solution
proposal including a preamble
and the agreed improvements
explained above
EUG
01/07/15
N/A
on-going
10.08
Page 32 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Table 15 : List of actions from CR resolution
Action
#
CR
Headline
Action
Responsi
ble
HW
expecte
d by
HW
review
expected
by
Status
To split CR1197 and draft a
solution proposal for its
remainder
ERA
24/06/15
01/07/15
on-going
10.09
Ambiguity regarding
1197 the temporary EOAs
and SvLs
10.10
1229
and
299
Age requirement for
estimated speed
and Version
compatibility check
To update the CR299 solution
proposal according to the
agreed U comments.
ERA
01/07/15
N/A
on-going
10.11
1229
and
299
Age requirement for To reflect on the need to add
estimated speed
an engineering rule in SUBSETand Version
040 for RBC’s hosting trains
compatibility check not supporting the 2.1 version
ERA
01/07/15
N/A
on-going
1237
KMS evolution
To clarify the expected
behavior if the ETCS on-board
needs to abort a
communication with a KMC
U
01/07/15
N/A
on-going
1254
Session
establishment
attempts to report
mode change
To review the ERA proposal
03/06/15
EUG/U
01/07/15
N/A
on-going
10.12
10.13
Red shaded lines stands for actions not fulfilled on time or with insufficient quality.
Page 33 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
7.4.
List of agreed solutions
This section provides, for information only, the agreed solutions for the CRs already solved in the
project, please take into account that these solutions are not definitive and they could be modified
during the project lifecycle.
Identification number
Headline
Reference Baseline Release
Documents and/or References
0239
Train data on TIU
2.3.0 (TSI CCS annex A modified by decision 2007/153/EC)
SUBSET 026-3, V2.3.0, 3.18.3.2, 3.19
SUBSET 026-5, V2.3.0, 5.4.3.2
SUBSET 034, V2.0.0, -
Error/Enhancement
Problem/Need description
Error
It is already well known that train data entry is one of the crucial task
with respect to the risk analysis of the overall system.
Therefore, DB would like to use the possibility mentioned in SRS
5.4.3.2 S12 to display data that was read from the TIU to the driver
for validation. This would allow for freight trains to force the driver
always to enter the data, and for train sets to read this information
e.g. from the diagnostic system.
Up to now, this input is not part of the TIU, although mentioned in
the SRS.
Additionally, for clarification, the requirement in S12 of 5.4.3.2
should be added to SRS 3.19.
Supporting document(s) for
problem/need description
Agreed Solution
Modify SUBSET-026 v3.4.0 as follows:
- In clause 3.13.2.2.6.1, replace "it shall be possible to configure the
on-board to" with "the on-board shall be configured to define".
Modify SUBSET-034 v3.1.0 as follows:
- Modify clause 2.6.2.1 to read: "The train data information is an
input that enables the ERTMS/ETCS on-board equipment to
determine values for any of those items of train data, which are
listed in §3.18.3.2 of [1]"
- Add new note 2.6.2.2 to read: “Note: The acquisition of train data
information from the train interface is an optional feature for the
ERTMS/ETCS on-board equipment.”
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
2008-01-09 07:15:20 PM
2015-04-22 05:02:08 PM
0539
Set speed indication for driver
2.3.0 (TSI CCS annex A modified by decision 2007/153/EC)
TS50459-2 §6.1.2.6 and SUBSET-034
Enhancement
Set-Speed control is implemented in a variety of rolling-stock in
service on different railways. This function allows a driver to set the
required cruise speed which is automatically maintained by the
Page 34 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
vehicle’s traction control system. ETCS must be capable of
supporting such systems in order to preserve existing performance
and operability standards. This feature is recognised in the
CENELC DMI standard which mandates that the selected set-speed
value is superimposed on the speedometer scale for vehicles fitted
with set speed control. Unfortunately, neither SUBSET-026 nor
SUBSET-034 contain a corresponding interface requirement to
support this function.
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
Modify SUBSET-023 v3.1.0, SUBSET-026 v3.4.0, SUBSET-027
v3.1.0, SUBSET-034 v3.1.0, ERA_ERTMS_015560 v3.4.0 as
described in the attachment "Solution_for_CR539_041114.docx"
Solution_for_CR539_041114.docx
2008-01-28 05:49:17 PM
2014-11-06 07:58:08 PM
0852
Definition of level 2/3 area and level transition border
Baseline 3 (1st consolidation release 02/2010)
Subset-026 v3.1.0, 3.5.5.1.
Error
The terms "RBC area" and "level 2/3" area are often used inside the
SRS but it is not stated, how the on-boards recognizes the borders
of an RBC area resp. level 2/3 area.
Moreover the difference between passing the level transition border
and receiving an level transition information inside an area is not
clearly defined. Thes cases need to be distinguished, because the
on-board functionality differs.
The clauses 3.5.3.7 a) and 3.6.5.1.4 state:
"the train passes a level transition border (from level 2/3 to level 0,
STM, 1) with its front end"
It is not clear how to understand it for instance for level transitions
inside a mixed level area. Which on-board behavior is expected if a
train is coming from an area where level 2/3 is permitted but not
operated by the train at the moment the level transition takes place?
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Modify SUBSET-023 v3.1.0 and SUBSET-026 v3.4.0 as described
in the attachment "Solution_for_CR852_EECT100615.docx"
Solution_for_CR852_EECT100615.docx
2010-09-12 08:11:27 PM
2015-06-16 05:42:46 PM
0933
Storing of RBC contact information
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
SUBSET-026 v3.3.0 §3.5.3; 4.10
Error
Page 35 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Problem/Need description
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
There is no requirement in the SRS about when the RBC contact
data has to be stored for a later use in case of RBC/RBC handover.
Further, the RBC contact data are deleted according to 4.10, when
entering level NTC or level 0 (via the transition to modes SN or UN),
but not when level 1 is entered. This is a miss.
Modify SUBSET-026 v3.4.0 as described in the attachment "SG
solution for CR933_EECT090315.docx"
SG solution for CR933_EECT090315.docx
2013-12-20 05:13:58 PM
2015-03-17 07:37:05 PM
1014
Duplicated balises ambiguities
Baseline 3 (1st consolidation release 02/2010)
Subset-026 v3.1.0
Error
When a balise group contains duplicated balises, it is not clear if the
telegram from a duplicated balise that is not used onboard shall be
considered as part of the balise group message or not. Clauses
3.16.2.1.2, 3.16.2.4.2 and 8.3.2.3 indicate that all telegrams are part
of the balise group message, while clauses 3.16.1.1.a), 3.16.2.4.8.2
and 8.4.1.4 indicate that unused telegrams from duplicated balises
are not part of the balise group message.
Clause 3.16.2.4.7 indicates that message counter values from
duplicated balise telegrams not used onboard must be checked if
the telegram is correctly decoded but shall be ignored it the telegram
is not received onboard. This is inconsistent from an hazard point of
view. The need to check the counter value of an unused telegram
cannot depend on if the telegram is received or not.
The ambiguities described above have lead to different
implementations that are not interoperable. This concerns both the
meaning of values 1 and 2 of the variable M_ERROR and if the
message counter M_MCOUNT value in a received but not used
balise telegram shall be checked or not.
Modify SUBSET-026 v3.4.0 as described in the attachment
"Solution_for_CR1014_091214.docx"
Solution_for_CR1014_091214.docx
2010-09-12 08:30:56 PM
2014-12-09 12:16:16 PM
1033
Disable Start in SR if no safe connection
Baseline 3 (2nd consolidation release 12/2010)
SUBSET-026 V320
ERA_ERTMS_015560 V320
Error
SRS clause 4.4.11.1.6 specifies that in level 2/3 in SR the driver
shall have the possibility to select Start, which results in an MA
Page 36 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
request. But if there is no safe radio connection at that moment it
makes no sense to press this button, because the MA request
cannot reach the RBC. It should be avoided to give wrong
expectations to the driver.
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
Modify SUBSET-026 v3.4.0 and ERA_ERTMS_015560 v3.4.0 as
described in the attachment "ERA_solution_for_CR1033.docx"
ERA_solution_for_CR1033.docx
2011-03-25 03:26:35 PM
2014-09-17 11:59:31 AM
1086
Unknown L1 LRBG reported to RBC
Baseline 3 (2nd consolidation release 12/2010)
SUBSET-026 V320
Enhancement
In the Swiss implementation a problem has been detected with
unknown level 1 LRBG reported to the RBC in the adjacent level 2
area. See EEIG384 attach.doc.
Based on this attachment we have the following 2 questions.
1) Is there from system point of view any justification for the severe
RBC reaction in case he receives an unknown balise when the level
transition is already announced to the onboard (item 2 in the RBC
reactions)?
2) From the 4 solution alternatives item 2 is from an engineering
point of view the best solution for the railways. Level 1 balises do not
need to be known to the RBC, the clear separation between level 1
and level 2 is achieved. No additional level 2 balises need to be
placed in the approach to the border, as might be the case with
solution 4. The remaining engineering restriction would be that there
are never more than 7 unknown balises between 2 known balises,
but this seems feasible. The only specification issue in solution 2 is
the restriction in 3.6.2.2.2b. In our view there is no hard technical
justification for this requirement. If the RBC uses any of the previous
7 balises the onboard will process the message in the normal way.
The question is therefore to relax this requirement, at least for the
approach area.
Supporting document(s) for
problem/need description
Agreed Solution
EEIG384 attachment.doc
Modify SUBSET-026 v3.4.0 as follows:
Modify 3.6.2.2.2 b) as follows: replace "the last relevant" with "a"
Add new clause 3.6.2.2.3.1 to read:
“Note: Figure 8 illustrates the case where the RBC uses as
reference the last received LRBGONB. The RBC could also use a
previously received one (see 3.6.2.2.2 b).”
Modify clause 3.6.2.2.2.2 as follows:
“Exception to b): When during SoM procedure the RBC has received
Page 37 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
from the onboard an unknown position or an invalid position which it
is not able to confirm, the RBC shall use an LRBG identifier set to
"unknown" until it receives a position report from the onboard having
validated its position by passing a balise group.”
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
2011-06-08 07:15:14 PM
2014-11-06 08:10:18 PM
1087
Manual network selection
Baseline 3 (2nd consolidation release 12/2010)
SUBSET-026 V320
ERA_ERTMS_015560, V3.2.0
Enhancement
Specifically on freight lines like the Betuwe Line it is common
operational practice to transport locos cold, i.e. in NP mode. During
this operation the cold loco may cross a border e.g. between
Germany and the Netherlands.
In the shunting yard Kijfhoek near Rotterdam the cold loco will
awake in the national ATB area, but it cannot always be avoided that
this happens quite close to the entry to L2 border, i.e. the loco will
not pass any network balise anymore, due to the minimum distance
required between network and RBC contact balises. When the
onboard awakes he still has the German network data and because
he is in a NTC area the driver cannot modify the network on the
DMI. This means that there is no way to enter level 2 in a normal
way.
Modify SUBSET-026 v3.4.0 and ERA_ERTMS_015560 v3.4.0 as
described in the attachment
"ERA_Solution_for_CR1087_220515.docx"
ERA_Solution_for_CR1087_220515.docx
2011-06-08 07:18:26 PM
2015-05-22 03:08:17 PM
1089
Ack for text messages in NL mode
Baseline 3 (2nd consolidation release 12/2010)
SUBSET-026 v3.2.0, 3.12.3, 4.5.2
Enhancement
According to SRS 4.5.2 the function “Manage Text Display to the
driver” is active in NL mode as specified in SRS 3.12.3.
SRS 3.12.3 specifies that an acknowledgement of a text message
from trackside can be requested from the driver and a service brake
or emergency brake application can be commanded if no
acknowledgement is provided.
That means that a train can be braked by the system if the driver of
a traction unit operating in NL mode does not acknowledge a text
message displayed on the DMI.
As such a driver is not always in a position to give the requested
Page 38 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
acknowledgement, this can lead to unwanted situations.
Supporting document(s) for
problem/need description
Agreed Solution
Remark: The issue has been analysed in the OH WG, see
supporting document "OH proposal Ack for text messages in NL
v1.doc"
OH proposal Ack for text messages in NL v1.doc
Modify SUBSET-026 v3.4.0 as follows:
Delete in table 4.5.2.1 the “X” for NL mode in the line “Manage Text
Display to the driver”
Delete in 4.7.2 the “A” in NL mode in the lines “Ackn of fixed text
information” and “Ackn of plain text information” of table “input
information” and in the lines “Fixed text information” and “Plain text
information” of table “output information”
Replace the “A” with “R” for the column NL in the lines “Fixed text
information” and “Plain text information” of table 4.8.4
Replace the “U” with “D” for the column NL in the lines “Fixed text
information” and “Plain text information” of table 4.10.1
Replace in 6.5.1.5.29 M_MODETEXTDISPLAY for value 11 “Non
Leading” with “Spare”
Replace in 7.5.1.73 M_MODETEXTDISPLAY for value 11 “Non
Leading” with “Spare”
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
2011-06-20 12:45:59 PM
2015-01-20 11:34:01 AM
1091
Insufficient driver information in OS
Baseline 3 (2nd consolidation release 12/2010)
SUBSET-026 V320
ERA_ERTMS_015560, V3.2.0
Enhancement
According to the SRS, OS mode enables a train to enter a section
that could already be occupied by another train or be obstructed by
any kind of obstacle (cf. Subset-026, 3.2.0, 4.4.12.1.1).
From this definition, it is evident that the driver shall check the track
occupancy, i.e. he shall primarily look outside.
In addition he shall check the DMI for any speed supervision
information, e.g. TSR within the OS area or EoA.
To efficiently fulfill his responsibilities, the driver shall be able to
recognize the relevant information on the DMI at a glance.
In our opinion, this is not possible with the current solution, because
speed restrictions are only visible when the driver has selected the
display of the “supervision data” and even then, the information is
not visible well in advance, requiring the driver to constantly check
the DMI (rather than the track occupancy).
EUG 30/09/14
The above problem/need description is fully replaced with the
following one:
The ERTMS specifications provide the possibility to show basic
Page 39 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
speed supervision information (the basic speed hooks in area B of
the DMI) to the driver in the modes SR and OS. Whether this basic
speed supervision is displayed depends on a toggle button which
can be operated by the driver. If we compare now the modes FS,
OS and SR, we see that in two of these three modes the driver has
not only the pure supervision information (area B of the DMI), but
additional information that helps him to anticipate the events that will
occur in front of him. In FS this is provided by the planning
information. In SR this is provided by the written order from the
signalman, with information on upcoming speed restrictions (see
clause 5.1.7 "Speed restrictions in SR" in TSI OPE annex A). In OS
such information is not provided, although the same information as
in FS is technically available for the whole OS MA.
From a human factors point of view it is important to give the driver
as much as possible advance information on the route he is
travelling. This is not only the case in FS mode, but equally in SR
and OS mode, where the driver primarily has to look outside. When
he anticipates what is coming he will be able to distribute his
attention between DMI (inside) and the track (outside) and he will
not be surprised by the events which he will encounter. Sinfo
provides the driver the trigger to act according the speed profile. The
combination of planning info and Sinfo is giving the driver the right
context to react appropriately.
An issue in the context of human factors is the following example
from lineside signaling: On SBB’s network, most signals passed at
danger (SPAD) occur, because the driver departs in a station when
the signal is still showing stop. Therefore, in the education of the
drivers it is emphasized that they shall never depart if the signal
does not show a proceed aspect. However, with the current
specification of the DMI for OS mode, this principle would have to be
violated in L2: If the train stands at the platform in OS mode, which
happens regularly due to track sharing in the station, and if the
signal is quite far away from the platform, the DMI is still in CSM. But
in CSM in OS, the driver has no information about whether a route is
set or not. The only thing he can do is to depart and look what
happens. In other words, drivers would have to be trained in L2 to
do something which is strictly forbidden in lineside signaling. From a
safety perspective, this is not acceptable. The driver needs to know
whether a route is set or not also in OS mode. This can easily be
achieved by showing the planning area in OS mode.
The combination of checking outside and inside without having had
the chance to anticipate on the forthcoming situation is for the driver
rather stressful. At a certain moment the Sinfo announces him to
check the DMI and to act accordingly. Sinfo is not only an indication
to tell the driver something about OS mode, it is also a general
indication to tell the driver something has changes on his DMI. The
driver knows that in OS mode the brake curve supervision exists
and will become active. Without planning info the driver is not able to
anticipate when he can expect a brake announcement.
Besides being stressful for the driver, lacking information about the
forthcoming situation may lead to operational delays too. If the driver
is not sure whether the route from the next signal marker board is
set and therefore may be passed, he may unnecessarily slow down
Page 40 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
instead of running at OS mode speed. If the planning area is
provided, the driver immediately gets the information about whether
he may pass the next signal marker board.
For SR additional information on speed restrictions is provided in
advance by the signalman, for FS the additional planning
information is available but in OS no information on speed
restrictions is provided in advance. To make the planning
information, in principle, available also in OS mode, will bring a
better balance in the information provided to the driver in SR, OS
and FS mode.
Note that not all railways want to show supervision information in SR
and OS mode. That depends on the specific operational concept
and it is the reason that the above mentioned toggle button exists.
To accommodate these different operational concepts, the display of
the planning information in OS mode can be controlled by this
existing toggle button.
General rule 1: give the driver the same operational information as
the technical system, i.e. speed profile, brake indication and audible
warning.
General rule 2: provide sufficient difference between the modes FS,
OS and SR.
- FS: full display (speed supervision and planning info)
- OS: reduced display (basic speed hooks and planning info)
- SR: reduced display (basic speed hooks and no planning info)
- Each mode is indicated with its own symbol.
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
Modifiy SUBSET-026 v3.4.0 and ERA_ERTMS_015560 v3.4.0 as
described in the attachment
"ERA_solution_for_CR1091_260515.docx"
ERA_solution_for_CR1091_260515.docx
2011-07-21 06:14:19 PM
2015-06-16 07:53:59 PM
1094
Unclear stop conditions for display of some DMI objects
Baseline 3 (2nd consolidation release 12/2010)
SUBSET-026 v3.2.0, ERA_ERTMS_015560 v3.2.0
Error
The DMI WG has checked the SRS and the DMI specifications in
order to identify the requirements qualifying as start/stop conditions
for the display of all driver's indications. This task has now been
completed. However, for the following DMI system statuses, their
stop condition is missing:
- Trackside malfunction (SRS 3.16.2.4.9)
- Trackside not compatible (SRS 3.5.3.8 b)
- Radio network registration failed (SRS 5.4.3.2 A29)
- SH refused (SRS 5.6.2 A220)
- SH request failed (SRS 5.6.4.1.2)
- Train data changed (without brake command) (SRS 5.17.2.2 A1)
Page 41 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
- Train is rejected (SRS 5.4.3.2 A40)
In addition, the stop condition for the system status 'Communication
error' (see SRS 3.14.1.7) is unappropriate when a service brake
command is initiated and a new consistent message is received just
after this brake command.
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
Modify SUBSET-026 v3.4.0, SUBSET-035 v3.1.0 and
ERA_ERTMS_015560 v3.4.0 as described in the attachment
"ERA_Solution_for_CR1094_130115.docx"
ERA_Solution_for_CR1094_130115.docx
2011-07-25 07:50:39 PM
2015-02-16 04:50:17 PM
1107
Status planning information on the DMI in FS mode
Baseline 3 (2nd consolidation release 12/2010)
SUBSET-026 v3.2.0, 4.7.2
ERA_ERTMS_015560 v3.2.0, 8.3.1.1
Enhancement
The DMI for ETCS is defined in ERA_ERTMS_015560 v320. The
planning information is described in chapter 8.3. For unclear and
unknown reasons this information is optional (SRS SUBSET-026
v320, table 4.7.2).
In the CENELEC Technical Specification (CLC/TS 50459-2), used
today as the basis for all manufacturers to built the DMI, chapter
6.3.1 describes the planning information. The only restriction is
given by stating that the planning information shall only be shown in
FS mode.
Today app. 95% of all DMI’s used in various engines and supplied
by various manufacturers are using and showing the planning
information described in the CENELEC CLC/TS.
The fact that this planning information is optional creates an
inconsistency in the interpretation of the presented information if one
DMI is equipped with this planning information and another one is
not equipped.
The planning information provides an essential element of drivers
information which is not provided by the other information on the
DMI (e.g. upcoming track conditions, gradient profile, length of the
MA, beyond the first speed restriction, starting point of the indication
area).
If drivers can’t rely on a coherent picture and information provided
by the DMI, they may need different training programs depending on
the type of vehicle they will use, Besides that, identical DMI’s will
support the interoperability and easy exchange of rolling stock and
drivers in the future.
Having different solutions on a harmonized interface creates
confusion and different human behavior when using the ETCS
system.
The need for the planning information was already recognized in the
first DMI studies done in the nineties under responsibility of the UIC
Page 42 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
(see attachment "Development of the ETCS MMI.pdf" (A200/M.F5945222-02.00-950228)). The basic principles were: giving accurate
actual information showing speed, brake curve, target distance and
track conditions; giving global but sufficient information about the
transmitted MA (anticipation, later called planning information) and
last but not least giving monitoring information about vital supervised
train systems such as pantographs, door systems and GSM-R
information.
It is unclear (no study and justified decision is known) why at a
certain moment the DMI specification was accepted, except the
mandatory use of the planning information.
Supporting document(s) for
problem/need description
There are however arguments and justifications known for a
mandatory planning information.
The arguments given by the letter of the representatives from ALE
and ETF in the OH wg ( see attachment "Letter_ETFALE_planning_area_mandatory.docx") are today valid and the result
of operational feedback from several hundreds of drivers using the
ETCS DMI with planning information today. Drivers with experience
on the Dutch, the Swiss, the Italian, the Spanish, the Austrian and
the UK ETCS lines are highly appreciating the planning info and
they would not understand why the European harmonized
specification would allow a DMI without planning information.
Development of the ETCS MMI.pdf
Letter_ETF-ALE_planning_area_mandatory.docx
Agreed Solution
Modify SUBSET-026 v3.4.0 and ERA_ERTMS_015560 v3.4.0 as
described in the attachment
"ERA_Solution_for_CR1107_190515.docx"
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
ERA_Solution_for_CR1107_190515.docx
Identification number
Headline
1117
Reception of an order to terminate a communication session while
session is being established
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
SUBSET-026 v3.3.0, §3.5.5.7
Error
The SRS clause 3.5.5.7 says that "In case an order to terminate the
communication session is received, while the communication
session is currently being established, the on-board shall abort the
process of establishing it and shall release the safe radio
connection".
This clause should be extended to all cases of termination of
session. For instance, when the driver closes the desk during a SoM
procedure.
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
2011-10-26 05:07:22 PM
2015-05-22 12:22:47 PM
Modify SUBSET-026 v3.4.0 as described in the attachment
"Solution_for_CR1117_081014.docx"
Solution_for_CR1117_081014.docx
Page 43 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Date of Submission
Last modification date
2013-12-20 05:27:33 PM
2014-10-14 06:27:29 PM
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
1122
Communication session establishment to report change to SL mode
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
SUBSET-026 v3.3.0 §3.5.3.4 c), 3.5.3.7 a), and 4.4.6.1.10 b)
Error
The clause 4.4.6.1.10 b) of the SRS says that in level 2/3, when
entering or exiting Sleeping mode, "the ERTMS/ETCS on-board
equipment shall open a communication session with the RBC to
report the change of mode to the RBC".
Considering that the entry in SL mode can be considered as an end
of mission (see SRS clauses 5.5.2.2.1 AND 5.5.2.2.1.1), this clause
does not read consistent with the SRS clause 3.5.3.4 c) which says
that the on-board shall establish a communication session if a mode
change, not considered as an End of Mission, has to be reported to
the RBC.
Also, there is no restriction regarding the number of attempts to
establish a session for reporting entry to or exit from SL, and none of
the conditions in 3.5.3.7 for stopping the attempts of session
establishment may ever be met. This would lead to permanently
ongoing attempts to establish a session for reporting a mode change
from/to SL, and thus the SoM may never be entered when leaving
SL in L2 in case no session can be established (see SRS clause
5.4.3.2 step S0).
Supporting document(s) for
problem/need description
Agreed Solution
Modify SUBSET-026 v3.4.0 as follows:
Replace clause 5.5.2.2 with « Intentionally deleted »
Replace clause 5.5.2.2.1 with « Intentionally deleted »
Replace clause 5.5.2.2.1.1 with « Intentionally deleted »
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
2013-12-20 06:16:00 PM
2014-10-14 06:47:31 PM
1125
Clarification of human role in ETCS safety analysis
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
SUBSET-091 v320 §4.2.1.11
Error
During the development of the Train Interface FFFIS, the TIU
experts group has identified a need to include the driver in the safety
analysis, in order to obtain realistic safety targets for certain
functions. It was noted that clear rules for when this is allowed are
missing in Subset-091.
Firstly, it is reasonable that Subset-091 shall contain such rules, in
order for each supplier not to end up with different conclusions.
Secondly, the "driver" should here be extended to "human" in order
to encapsulate also other personnel, such as maintainer and
signalman.
Page 44 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Thirdly, it is believed that different principles shall be applied
depending on which human failure is studied:
(1) "Pure" human failures, against which ETCS has no chance to
protect. Examples are bad maintenance, hazardous isolation of
ETCS Onboard or hazardous (if unprotected) signalman commands.
According to the original definition of THR_ETCS from ESROG,
carried forward in Subset-091 §4.2.1.11, this type of human failures
is not included, i.e. does not have to burden THR_ETCS. The text in
§4.2.1.11 should be clarified.
(2) The driver fails to drive the train safely. Here, the ETCS can
protect, using the technical functions specified in Subset-026.
The conceptual fault tree in Subset-088 indicates this type of failure
as included in the ETCS Core Hazard and thereby in THR_ETCS. If
there is a need to quantify this failure (as has been done for balise
detect in Subset-088 Annex A), conservative principles shall apply.
(3) The human fails to protect against an ETCS failure. Examples
could be erroneous speed measurement that the driver has a
chance to discover.
It is not the personnel’s responsibility to discover ETCS failures.
Therefore, Subset-088 Part 3 §5.4.1.3 forbids to credit this
protection (denoted driver vigilance). This should be more clearly
stated in Subset-091, since Subset-088 is not mandatory.
Supporting document(s) for
problem/need description
Agreed Solution
Modify SUBSET-091 v3.3.0 as follows:
Modify clause 4.2.1.11 to read:
“The hazards and their associated THR relate to the failure to
perform the function of ETCS as defined in 4.2.1.6. This function is
achieved with the ERTMS/ETCS Reference Architecture as defined
in the SRS. Thus:
a) Failures due to operators (e.g. driver, signalman and
maintenance staff) and operational rules against which ETCS is not
designed to protect according to the SRS, are not included in these
hazards or their THR (see Subset-088 Part 3, §7.2.1.1 and Subset118, §3.2.1.3 for details).
b) When analysing errors against which ETCS is designed to
protect, the operator errors have been quantified in the scope of the
THR calculation for ETCS failures, in a degree depending on the
ETCS mode defined in Subset-026.
c) If a failure is initiated by the ETCS On-board resulting in the
display of incorrect information, the driver vigilance has been
considered in THR calculation for this failure. When the driver
vigilance and resulting actions have been quantified in a safety
analysis, it has been done in a conservative way.
The quantification for the driver operational assumptions is given in
section 10.4.”
Modify clause 14.1.1.2 to read: "The protective features listed below
are based on the inherent features designed into ETCS and may be
claimed as mitigations in a supplier’s specific safety analysis. These
mitigations depend on ETCS operating modes, as explained in
10.3.1.2."
Page 45 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Modify clause 10.4.1.8 to read: "These rules cover situations where,
if a driver fails to obey information a hazardous situation could
result."
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
2013-12-20 06:39:46 PM
2015-05-19 04:24:29 PM
1128
Passing Level 0 / Level NTC border in PT mode
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
SUBSET-026 v3.3.0 §5.11.4, 4.6.2, 4.6.3
Error
A train may be tripped (for whatever reason) and then come to a
stand a short distance in rear of a Level 0 or Level NTC transition
border. If the level transition has already been announced when TR
mode is entered, it will continue to be stored and will be unaffected
by the transition to TR and PT modes. Furthermore, the level
transition announcement may be received while the train is in TR or
PT modes.
Once the driver has acknowledged the train trip there is a transition
to PT mode and the brakes are released. The release of the brakes
could lead to an unintentional forward movement and the estimated
front end passing the announced transition border, requiring a
transition to Level 0 or Level NTC. However, no mode transitions are
defined in Subset-026 to handle these cases.
These gaps should be closed by defining the onboard behaviour if a
Level 0 or Level NTC border is passed while in PT mode.
Supporting document(s) for
problem/need description
Agreed Solution
Modify SUBSET-026 v3.4.0 as follows:
Add the following transitions to 4.6.2 (Mode Transition Table) and
4.6.3 (Transition Conditions Table):
PT to UN with condition [75] and p5.
[75]: (the ERTMS/ETCS level switches to 0) AND (valid Train Data is
on-board)
PT to SH with condition [76] and p5.
[76]: (the ERTMS/ETCS level switches to 0 or NTC) AND (no valid
Train Data is on-board)
PT to SN with condition [77] and p5:
[77]: (the ERTMS/ETCS level switches to NTC) AND (valid Train
Data is on-board).
Modify table 4.8.4 as follows:
- In line “Level Transition Order and Conditional Level Transition
Order”, column “PT”: replace “A[1] [5]” with “A[1]”.
- Below the table, replace the exception [5] with “[5]: Intentionally
deleted”
Add new clause 5.11.4.3 to read:
“In case a transition to Level 0 or Level NTC occurs while in PT
mode, the process shall go to D085.”
Page 46 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Modify figure 8 of chapter 5 to drag back the grey area of TR mode
so as to not include the diamond boxes D080, D085, D090.
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
2013-12-20 06:58:29 PM
2015-01-20 02:19:39 PM
1129
DMI indication of level announcement in SB
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
Subset 26-4 v3.3.0, 4.7.2 table
Error
In SRS 4.7.2, no DMI indication of a level announcement is foreseen
for mode SB. However, level transition announcements are
accepted in SB, so there can be a need to indicate them (e.g. in
L2/3 an RBC may send an LTO for further location without MA).
Modify SUBSET-026 v3.4.0 as follows:
Add new clause 5.10.4.1.2 to read: “Exception to 5.10.4.1.a): in SB
mode, the driver shall be requested to acknowledge the level
transition only when the level changes.”
2013-12-18 07:59:34 PM
2015-02-16 04:53:25 PM
1163
Train interface – Track conditions related outputs to be harmonized
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
SUBSET-034 v3.0.0, §2.3.4; 2.3.5; 2.4; 2.8
SUBSET-026 v3.3.0, §3.7.3.2; 3.12.1.5
Error
All outputs regarding track conditions where an initial state can be
resumed, or where a remaining distance is supposed to be sent –
via the train interface – to an external device, are marked in Subset034 as "to be harmonized". The problem has two different aspects:
1) Resuming of initial state. SRS §3.7.3.2 stipulates that the onboard
shall resume initial states beyond a given location individually
through a single request, for all stored track condition information of
the types described in the attached table (see file "CR1163 –
attachment to problem description"). However, it is not clear how the
resuming of an initial state can be performed. In the example of the
powerless section with pantograph to be lowered: let’s imagine the
onboard has received a track condition of that type indicating that a
powerless section is ahead of the train. The on-board sends the
information indicating the remaining distance to an external function:
- What happens if, before the train reaches the beginning of the
section, the track condition is deleted, or if a new track condition of
the same type with different distance information is received?
Page 47 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
- In case the ETCS command had been transmitted to the train: how
can the command be taken back?
2) Remaining distance. SRS § 3.12.1.5 stipulates that the on-board,
on reception of a track condition (of a certain type – see table below)
shall “send information with the remaining distance to an
ERTMS/ETCS external function”. It is not clear how this “remaining
distance” can be transmitted via the train interface: the external
function has no position reference common with the on-board (i.e.
LRBG and distance from it). The same issue applies for the
resuming of initial state, since SRS §3.7.3.2 stipulates that
ERTMS/ETCS on-board equipment shall resume initial states
beyond a given location: how to send this given location to the
external function?
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
CR1163 - attachment to problem description.pdf
Modify SUBSET-026 v3.4.0, SUBSET-027 v3.1.0, SUBSET-034
v3.1.0 and SUBSET-040 v3.3.0 as described in the attachment
"CR1163_solution_041114.docx"
CR1163_solution_041114.docx
2012-12-20 01:24:28 PM
2014-11-06 08:20:30 PM
1164
Ambiguity in assignment of coordinate system
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
SUBSET-026, v3.3.0, §3.4.2.3.3
Error
An interoperability issue has been encountered while testing on a
Level 2 project; the issue relates to the expected onboard behaviour
when assigning coordinate system to a single balise group and it is
relevant to both v2.3.0d and v3.3.0 of Subset-026. See attached
document "CR1164 – attachment to problem description".
CR1164 attachment to problem description.pdf
Modify SUBSET-026 v3.4.0 as described in the attachment
"ERA_solution_for_CR1164_130527.docx"
ERA_solution_for_CR1164_130527.docx
2013-01-24 04:33:09 PM
2014-09-17 12:59:17 PM
1167
Juridical data for the equivalent brake build-up time
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
Subset 026 clause A3.9.4 and A3.9.6.
Subset 027 v3.0.0 section 4.2.4.2
Error
For a lambda train, the subset 027 offers the possibility to provide as
juridical data only one value of the service brake delay per specific
configuration of the special brakes (see the section 4.2.4.2 of Subset
027 v3.0.0, variable “T_BRAKE_SERVICE(k)”).
Page 48 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
This is not in line with the SRS clause A.3.9.4 which specifies that
the conversion model computes two values of the equivalent brake
build up time for the service brake:
- T_brake_service_cm0 when V_target = 0
- T_brake_service_cmt when V_target > 0
Even if T_brake_service_cmt and T_brake_service_cm0 only differ
by the coefficient kto, it cannot be concluded that the juridical
recording of one of the two times will allow to reconstruct the second
time.
As specified in SRS clause A3.9.6, the coefficient kto may take other
values than the ones specified in the SRS if justified by the specific
brake system of the train.
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
Modify SUBSET-027 v3.1.0 as described in the attachment
"ERA_solution_for_CR1167_180914.docx"
ERA_solution_for_CR1167_180914.docx
2013-12-18 08:24:57 PM
2014-10-14 06:51:56 PM
1169
Ambiguity about the variable L_STMPACKET in juridical data STM
INFORMATION
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
SUBSET 027 v3.0.0, SUBSET 058 v3.0.0
Error
The content of this message is conditioned by the value of the
variable NID_STMEVENT.
In case the value of this variable is equal to 2 meaning
“Reception/sending of STM packet”, the message contains the
variables NID_STMPACKET and L_STMPACKET, followed by the
variables of the STM packet to transmit to the exception of the
variables NID_PACKET and L_PACKET.
It is clear that the variable NID_STMPACKET value has to equal to
the value of the NID_PACKET of the STM packet to transmit.
It is however not clear how has to be determined the value of the
variable L_STMPACKET.
The column “Comment” in the message description says the
following regarding the value of this variable: “length of
M_STMPACKETDATA”. This is no help because the variable
M_STMPACKETDATA does not exist in the Subset 027.
The description of the variable L_STMPACKET says nothing.
The range of values of the variable shows that the maximum value
of this variable is 1867 (bits).
In the Subset 058 (see 8.1.10), the variable L_PACKET is defined
as indicating the length of the transmitted packet in bits, including
NID_PACKET, L_PACKET, Q_SCALE (if included) and all other
packet variables. The maximum value for the variable L_PACKET is
1888 (bits).
Knowing that the length of the variable NID_PACKET is 8 bits and
the length of the variable L_PACKET is 13 bits, it can be deduced
that the variable L_STMPACKET represents the total length of the
Page 49 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
STM packet to transmit excluding the variables NID_PACKET and
L_PACKET.
The variable L_STMPACKET should however be clearly defined in
the Subset 027.
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
Modify SUBSET-027 v3.1.0 as described in the attachment
"ERA_solution_for_CR1169_190914.docx"
ERA_solution_for_CR1169_190914.docx
2013-12-18 08:28:48 PM
2014-10-14 06:59:26 PM
1172
Problems related to level crossing supervision
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
SUBSET 026 v3.3.0
Error
Problem 1:
SRS clause 5.16.1.1 specifies that “In case the LX is not protected,
the ERTMS/ETCS on-board equipment (in FS, LS or OS mode)
shall temporarily supervise the LX start location as both the EOA
and SvL (instead of the EOA and SvL given by the MA), with no
release speed.”
SRS clause 5.16.1.2 specifies that “The supervision of the LX start
location as both the EOA and SvL shall be substituted by the
inclusion of the LX speed restriction in the MRSP under conditions
depending on whether stopping in rear of the LX start location is
required or not.”
The conditions for this substitution are specified in SRS sections
5.16.2 and 5.16.3.
SRS section 5.16.2 specifies that in case stopping in rear of nonprotected LX is required, the substitution takes places once the train
has stopped with its estimated front end inside the stopping area.
SRS section 5.16.3 specifies that in case stopping in rear of the nonprotected LX is not required, the substitution takes place when the
train reaches the location of the braking to target Permitted speed
supervision limit calculated for the LX speed (SRS 3.13.9.3.5.11&12
provide the details for the calculation of this location).
SRS section A.3.5 specifies that regarding actions executed in
reference to location information received from trackside, the onboard equipment shall ensure that the action related to a location is
neither reverted, nor executed twice. This section provides a list of
actions to which this rule applies. The action “Substitute EOA/SvL
supervision of LX start location by the inclusion of the LX speed
restriction in the MRSP” does not appear in this list.
This would mean that substitution has to be reverted in case of
reverse movement (initiated by driver or due to roll-away) or
adjustment of train position on passing a new LRBG.
However, there is no clear “reverting trigger event” specified in the
SRS, in particular for the case where the substitution took place
because the train reached standstill in rear of the LX.
Problem 2:
SRS 3.13.9.3.5.11 specifies the assumptions that will be made to
Page 50 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
calculate the location of the Permitted speed supervision limit, valid
for the LX speed, that is used to determine the location where the
supervision of the LX start location is substituted by the supervision
of the LX speed. These assumptions are the following ones:
a) the estimated acceleration shall be set to “zero”
b) if not inhibited by National Value, the compensation of the
inaccuracy of the speed measurement shall be set to a value
calculated from the LX speed, as defined in SUBSET-041 § 5.3.1.2:
V_delta0lx = f41(V_LX)
Except in specific cases, these assumptions lead to a calculated
Permitted speed limit which will be different from the one used to
supervise the EOA/SvL located at LX start location: the Permitted
speed limit used to supervise the EOA/SvL located at LX start
location is computed with the measured estimated acceleration and
the current speed inaccuracy while the Permitted speed limit used to
locate the substitution is computed with a null acceleration and
Subset-041 speed inaccuracy values.
Considering that the train is approaching a target (the LX start
location supervised as an EOA/LOA), and therefore that the driver
will likely be braking the train, the Permitted speed limit calculated
for the substitution, which according to its calculation assumptions
does not consider the driver brake application, could be more
restrictive than the Permitted speed limit used to supervise the
EOA/SvL located at LX start location. It has also to be noted that a
performing speed estimation (i.e. performing better than the Subset
SUBSET-041 § 5.3.1.2 requirements) will reinforce this situation.
As a consequence, at the time of substitution, the supervised
Permitted speed limit, as well as Warning and Intervention limits,
could decrease abruptly as represented in the attached picture (see
file “CR1172 Attachment to problem description.pdf”).
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
CR1172_Attachment_problem_description.pdf
Modify SUBSET-026 v3.4.0 as described in the attachment
"ERA_solution_for_CR1172_081014.docx"
ERA_solution_for_CR1172_081014.docx
2013-12-18 08:44:18 PM
2014-10-14 07:01:55 PM
1180
Guard rails and cables in the vicinity of balises
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
SUBSET-036 v3.0.0, § 5.7.10.4.1, 5.7.10.7.2, 6.6.10
Error
Two series of questions have been raised by RailCorp (Australia) in
relation to guard rails and cables installed in the vicinity of
euroabalises, see attachment "Railcorp requests.pdf".
The replies forwarded by UNISIG (see attachment "Reply to query
on guard rails and cables.pdf") do not fully address the questions
raised by RailCorp.
1) Regarding guard rails: the SUBSET-036 clause 5.7.10.4.1
stipulates that the rail shall be cut, leaving a gap of at least 20 mm.
However it does not specifically stipluates that this 20mm gap
Page 51 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
should be made of air, while the solution provided by RailCorp (the
"Benkler joint") provides well a gap made of a 20mm end post
insulation. The UNISIG answer ("this solution is not compliant to
Subset-036") appears therefore poorly justified.
Supporting document(s) for
problem/need description
2) Regarding cables: in the attachment "Railcorp requests.pdf", the
supplier claims that exclusion zone does not apply to the cable
connected to the balise ("by definition"). UNISIG does not answer
this question and in addition it is unclear whether the cables
connected to the balise are covered by the provisions of the
SUBSET-036.
Railcorp requests.pdf
Reply to query on guard rails and cables.pdf
Agreed Solution
Modify SUBSET-036 v3.0.0 as follows:
Add new sentence at the end of section 5.7.10.4.1 to read: "The
meaning with gaps above is that it is either free air, or filled with
dielectric material".
Add new sentence at the end of section 5.7.10.7.2 to read: " For the
Interface ‘C’ cable, all installation rules shall be defined by the
supplier of the balise. However the maximum induced currents
specified above shall be respected. "
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
2013-03-25 04:41:12 PM
2014-11-10 04:55:18 PM
1187
Indication marker inconsistency
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
Subset-026 330
ERA_ERTMS_015560 v330
Error
In SRS 3.3.0, 3.13.9.3.6.1, it is specified that the indication
supervision limit is calculated based on the estimated speed. The
DMI specification 3.3.0 (ERA_ERTMS_015560 v330) reflects this in
figure 11.
However, for the indication marker, it is stated in the DMI
specification, clause 8.3.8.3, that “the bottom of the indication
marker shall be at the location where the TSM related to the current
target starts i.e. at the location where the braking to target indication
supervision limit intersects the MRSP”.
Regarding the current definition of the indication marker, there are
two issues:
1.
The implicit definition of TSM in clause 8.3.8.3 is not
consistent with the definition of TSM in the SRS. In clause
3.13.10.6.1, TSM is specified being entered if the train either passed
with the max safe front end the pre-indication location calculated
from an EBD or with the estimated safe front end the pre-indication
location from the SBD.
Page 52 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
2.
More importantly, due to ergonomical and signalling
reasons, it is problematic to define the location of the indication
marker dependent on the MRSP speed. If the train is not running at
MRSP speed, e.g. after the MRSP has jumped to a higher speed
(e.g. after the train has passed a TSR), the location of the indication
marker and the location of the indication supervision limit do not
match. In this scenario, the indication marker might reach the bottom
of the planning area, but the point in time to operate the brakes,
defined by the indication supervision limit, is not reached yet.
Because of this inconsistency, the driver will be confused and
cannot rely on the indication marker anymore.
This behaviour of the DMI was observed on a loco with an 2.3.0d
onboard with the behaviour of the indication marker according to the
baseline 3 DMI specification (this has been confirmed by the
supplier). The drivers reported this behaviour of the DMI as an error.
The inconsistency between indication marker and indication
supervision limit is very confusing for them. They don’t see any
benefit at all. The drivers require that the indication marker shows
the location of the indication supervision limit at estimated speed for
the current target (like on many B2 onboards today). This means
that as soon as the indication marker reaches the bottom of the
planning area, the indication status is entered.
If the indication marker is calculated based on MRSP speed there is
also a negative impact on signalling. Since the indication marker is
considered by the drivers as order to brake, they brake too early if
the train is not running at MRSP speed. To avoid the braking, the
MA has to be prolonged earlier than necessary. In a headway
scenario this results in shorter than necessary blocks.
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
Modify SUBSET-026 v3.4.0 and ERA_ERTMS_015560 v3.4.0 as
described in the attachment
"ERA_Solution_for_CR1187_210515.docx"
ERA_Solution_for_CR1187_210515.docx
2013-07-17 05:27:22 PM
2015-05-22 12:34:32 PM
1188
Balises in Multi-Rail Track
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
SUBSET-036 v300
Error
Multi-rail track has been adopted in the Spanish network as a
solution to the implementation of the European directives in order to
facilitate the access to the network to TSI compliant vehicles.
It is therefore necessary, to include the multi-rail concept also in the
characterization of the control command and signaling system, in
particular to the subset-036.
The need to include this concept in subset-036 is the lack of any
definition for how to define the reference axis that has to be taken
into account in muti-rail track scenarios for the restrictions of
Page 53 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
installation of Eurobalises and the deviations allowed.
This definition is necessary at a project design stage as well as for
the certification stage.
This lack of definition for the multi-rail track scenario is even more
alarming since this kind of clause is already included for the
installation of the Euroloop in the new update of subset-044.
This definition is equivalent to the already existing definition for
multi-rail track in the energy and infrastructure TSI.
Supporting document(s) for
problem/need description
Agreed Solution
Modifiy SUBSET-036 v3.0.0 as follows:
Add new sentence at the end of section 5.6.2.3 to read:
"Note: in case of multi-rail track, where one or more track(s) are
operated with ETCS, one Balise can be installed serving several
tracks as long as the installation of the Balise is in accordance with
the rules above when each track is considered individually. Where it
is not possible for one Balise to serve several tracks, several Balises
can be installed, where each Balise serves one track, as long as
each Balise is installed according to the above rules for the track it is
intended to serve. In case several Balises are installed as described,
a Balise may or may not be read/detected if installed outside the
limits defined above, with reference to the track on which the train is
running."
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
2013-08-01 02:09:44 PM
2014-11-07 12:23:07 PM
1190
UES text message end condition
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
SUBSET-026 V330
Enhancement
In the context of the planning for the B3 maintenance releases the
EUG has recently evaluated whether CR1077 is still relevant. The
conclusion was that a specific icon for Emergency Stop is not
needed. The brake icon will be displayed together with the text
message "Emergency Stop" which only explains the reason why the
brake has been commanded.
The conclusion was therefore that CR1077 could be rejected, but
the evaluation revealed some issues related to the end condition of
the "Emergency Stop" text message. These issues are addressed
here. They are relevant only for the Unconditional Emergency Stop,
because this will trigger a transition to trip mode. The relevant
onboard behaviour is explained here.
SRS clause 3.10.2.6 says: "The driver shall be informed when
emergency stop(s) have been accepted and are not yet revoked".
Our interpretation of this clause is that as soon as one ES is
accepted the driver shall be informed (i.e. the text message
"Emergency Stop" on the DMI) and only when all ES are revoked,
the information disappears from the DMI. I.e. the end conditions is
Page 54 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
"all ES revoked".
An accepted UES onboard will immediately trigger a transition to TR
mode. According to SRS clause 4.4.13.1.3 the reason of the trip
shall be indicated to the driver. In the case of UES this indication is
the text message "Emergency Stop". Since this indication of the
reason of the trip is specified for TR mode, the mode transition
TR>PT is the end condition.
The above mentioned behaviour revealed the following two issues.
1) The reason of the train trip is indicated only in TR mode, not in PT
mode. The harmonised operational rules for B3 (draft 3, version
2.1.8) article 6.41.1 says in both situations a) and b) that when the
request to acknowledge trip appears on the DMI, the driver shall
acknowledge (which will trigger the transition from TR to PT mode)
and as soon as PT mode is indicated he shall continue the trip
procedure, i.e. contact the signaller. It means that reason of the train
trip is displayed in TR mode, when there is nothing that the driver
can do with it, while in PT mode, when he may need it to explain to
the signaller what happened, the reason of the train trip has already
disappeared. Discussions with operational experts from CER and
EIM revealed that the limitation to TR mode was not an intentional
choice of these experts. The proposal is therefore to extend the
reason for the train trip to PT mode. Of course this proposal needs
to be confirmed by the operational experts.
2) Because the text message "Emergency Stop" serves two different
purposes, i.e. indication of at least one accepted and not yet
revoked UES onboard and the reason of the train trip, there are 2
start and 2 end conditions. The start conditions (UES accepted and
transition to TR mode) coincide by definition (UES will trigger the
transition to TR mode) that creates no problem. But the end
conditions (all ES revoked and exit TR mode, or exit PT mode as
proposed above) do not coincide by definition. The logical
combination of the end conditions is however not defined. This gap
in the specifications has to be filled. Note that this proposal has
been discussed with EIM/CER OPE experts.
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
Modify SUBSET-026 v3.4.0, ERA_ERTMS_015560 v3.4.0 as
described in the attachment "Solution_for_CR1190_091214.docx"
Solution_for_CR1190_091214.docx
2013-07-17 05:21:26 PM
2014-12-09 12:25:29 PM
1221
Availability of Override and Start buttons
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
SUBSET-026 v3.3.0
ERA_ERTMS_015560 v3.3.0
Error
This problem description is composed of 3 items:
Item 1: There seems to be an inconsistency between the DMI
specification and SRS with regards to the availability of the override
button. According to the SRS 5.8.2.1
“The ERTMS/ETCS on-board equipment shall allow the driver to
select “Override” (i.e. the “Override” button becomes available) only
Page 55 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
when:
a)
The train speed is under or equal to the speed limit for
triggering the override function (national value) AND
b)
The current mode is Full Supervision, Limited Supervision,
On Sight, Staff Responsible, Shunting, Unfitted, Post Trip, Stand By
(in level 2/3 only) or SN (National System) AND
c)
Validated Train Data is available (except when already in
Shunting mode).”
From this it is clear that validated train data is required in all cases
except when in SH mode.
However, the DMI specification in Table 34 states that, for all modes
except SB, the override EoA button is enabled when
“(train speed is under or equal to the speed limit for triggering the
“override” function) AND (mode is FS/LS/SR/OS/UN/PT/SN/SH)”
Note that there is no mention of validated train data. In the DMI
specification the requirement for valid train data is only explicitly
stated for SB mode.
Now consider the scenario of a train in L2 SH mode, without valid
train data. The train reads Danger for SH and transitions to TR.
According to the Train Trip procedure in 5.11, as well as the mode
transition table, if the train is in Level 2 then the onboard will
transition to PT mode once the driver has acknowledged the trip (the
transition sequence SH>TR>SH only applies to Levels 0/NTC, not
Levels 1/2/3). Therefore, the train is now in L2 PT mode without train
data onboard.
According to the SRS the override button is not enabled in this case.
However, according to the DMI specification the override button is
enabled.
Item 2: DMI specification §11.2.2 Table 34 states that valid Train
data are required for availability of the Override button in SB.
However, for availability of the Start button in SB (which in L1 will
also cause a transition to SR), DMI specification §11.2.1 Table 33
states in addition that a valid Train running number is required.
This reads as inconsistent.
Item 3: according to DMI specification figure 137 it is mandatory that
the Train running number is getting validated after S3-2 (if not
already valid). However, it is not clear what happens if the driver
chooses 'cancel' in S3-3. Does this lead back to the Train data
validation window, or to the Main window?
If the latter, is it correct to assume that the Override button would
then be available, but not the Start button?
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Modify SUBSET-026 v3.4.0, ERA_ERTMS_015560 v3.4.0 as
described in the attachment "Solution_for_CR1221_091214.docx"
Solution_for_CR1221_091214.docx
2013-12-18 01:00:37 AM
2014-12-09 12:39:13 PM
1222
Inconsistency regarding list of BGs for SH area
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
Page 56 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Documents and/or References
Error/Enhancement
Problem/Need description
Supporting document(s) for
problem/need description
Agreed Solution
SUBSET-026 v3.3.0
Error
SRS clause 8.4.4.4.1 specifies that it is possible to include the
Packet 49 (List of Balises for Shunting Area) inside a “Request to
Shorten MA” message.
However the “Request to Shorten MA” message in section 8.7.5 of
the SRS includes only the packet 80 as optional packet.
This reads as inconsistent.
According to section A3.4 of the SRS, upon granting a cooperative
shortening request the onboard will automatically delete the List of
Balises for SH Area.
It seems, therefore, that there is no reason to allow Packet 49 in a
Request to Shorten MA message, as it will never be used by the
onboard.
Modify SUBSET-026 v3.4.0 as follows:
Modify table 8.7.5 row #7 as follows:
Modify column "VARIABLE" to read "Optional packets"
Delete "Packet 80" in column "Remarks"
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
Supporting document(s) for
problem/need description
Agreed Solution
2013-12-18 01:16:45 AM
2014-09-17 01:06:12 PM
1229
Age requirement for estimated speed
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
Subset-041 V310
Enhancement
ProRail is currently investigating the possibility to use the position
and speed information from the ETCS onboard in the position report
to the RBC to trigger the activation of level crossings in the
Netherlands.
For such a function the moment at which the values are determined
onboard is a critical parameter. Subset-041 clause 5.3.1.3 gives a
requirement on the age of the position value in the position report.
The equivalent requirement for the speed value in the position report
is however not specified in the Subset-041. Without such
requirement the activation of LX on the basis of the position report
cannot be implemented with the required safety level.
Modify SUBSET-041 v3.1.0 as follows:
Modify section 5.3.1.3 as follows:
Replace "Age of position measurement" with "Age of speed and
position measurement" (two occurrences)
Replace "The position of the train front indicated in a position report"
with ""The speed and the position of the train front indicated in a
position report"
Supporting document(s) for
Page 57 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
Supporting document(s) for
problem/need description
Agreed Solution
2014-01-09 12:26:48 PM
2015-06-17 01:10:28 PM
1236
Criteria for Levels in train unclear
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
Subset-026 V330
Error
SRS 2.6.2.5 specifies the downwards compatibility of levels by using
the concept, nowhere defined, of "level x equipped train". There are
however no criteria defined to determine the level for which a train is
equipped: the only clauses that we could find in the SRS refer not to
the “equipment” but to the "availability" of levels: see SRS
5.10.2.4.1a (condition for level 2/3 to be available) and 5.10.2.4.1c
(level 0/1 available by definition). These clauses therefore do not
clarify the expression "level x equipped train" mentioned in 2.6.2.5.
The concept of a train equipped for a “Level x” seems also not
justifiable in terms of functionalities, because there seem to be no
clauses in the SRS restricting certain functions to specific levels. For
the modes, in the SRS there is a table that specifies in which modes
the on-board functions are active or not (§4.5.1.1.) whereas for the
levels there is no such table: we assume therefore that every
onboard contains all functionalities related to all ETCS levels and
that therefore, functional-wise, an ETCS onboard is “equipped” for
all Levels.
Note that it is the understanding of several members in EUG that an
ETCS on-board shall fulfil the whole SRS, i.e. all functionalities
defined for the use in all levels, which would mean that there is no
such thing as downwards compatibility. Some others are of the
opinion that there could be onboards compliant with the
specifications while they do not fulfil the whole SRS, e.g. only L0
and L1. It is therefore essential to clarify the correct interpretation of
2.6.2.5.
In conclusion, clause 2.6.2.5 has to be modified or expanded in
order to clarify what does it mean that a train is equipped for a
“Level x”.
Modify SUBSET-026 v3.4.0 as follows:
Replace clauses 2.6.2.5 and 2.6.2.6 with “Intentionally deleted”.
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
2014-01-06 04:56:49 PM
2014-11-10 04:59:59 PM
1242
Several problems with STM specifications
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
Subset-035 v3.1.0; SUBSET-057 v3.0.0; SUBSET-058 v3.1.0;
SUBSET-059 v3.0.0; ERA_ERTMS_015560 v3.4.0
Page 58 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Error/Enhancement
Problem/Need description
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
Error
Following the Baseline 3 first release and first maintenance release,
a number of mistakes in the STM specifications have been spotted
as return of experience.
The selected mistakes are appended in the file
"Attachment_problems_STM_spec_20140722.doc", together with
the proposed solutions.
Attachment_problems_STM_spec_20140722.doc
Modify SUBSET-035 v3.1.0, SUBSET-057 v3.0.0, SUBSET-058
v3.1.0, SUBSET-059 v3.0.0 and ERA_ERTMS_015560 v3.4.0 as
described in attachment "Solution_for_CR1242_140115.doc"
Solution_for_CR1242_140115.doc
2014-07-01 06:38:34 PM
2015-02-16 04:54:24 PM
1245
Display of ETCS override in level NTC
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
Subset-026 V340
Subset-035 V310
ERA_ERTMS_015560 V340
Error
If a national override procedure is activated and ETCS is informed
about that, then also ETCS will activate its override procedure
according to sub-035 10.10.2.1. In this situation both systems will
indicate their own override symbols. That ETCS is indicating its
symbol is written in; sub-026, 5.8.3.7 and table 4.7.2, and in DMI
spec. 8.2.3.1.9. When a national stop signal is passed, the national
symbol will disappear, but the ETCS symbol will remain until the
override procedure in ETCS is ended.
In B2 it is possible to inhibit the display of the ETCS override status
via Q_INDICATE, but in B3 this variable is deleted.
It is confusing to show the ETCS override on a pure NTC line. It is
even more confusing to still show the ETCS override symbol after a
national stop signal has been passed on a pure NTC line. Is this
really the intention?
Supporting document(s) for
problem/need description
Agreed Solution
Modify SUBSET-026 v3.4.0 as follows:
Add new clause 5.8.3.7.1 to read “Exception 1: in case the Override
function has been activated by an STM (see Subset-035), the status
“override active” shall not be indicated to the driver.”
Add new clause 5.8.3.7.2 to read “Exception 2: in case the Override
function has been activated by selection of “Override” while being in
level 0, 1, 2 or 3, the status “override active” shall stop to be
indicated to the driver on executing a transition to level NTC.”
Modify ERA_ERTMS_015560 v3.4.0 as follows:
Page 59 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Modify clause 8.2.3.1.9 to read: “Symbol MO03 (active override)
shall be shown as long as the override function is active and has to
be displayed (see [1]).”
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
2014-07-10 05:50:00 PM
2015-03-17 07:45:45 PM
1250
Incorrect description in gradient profile
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
SUBSET-026 V340
Error
The description in 7.4.2.6 Packet Number 21: Gradient Profile:
” The gradient value is the minimum gradient for the given distance.”
and in 7.5.1.37 G_A:
“This is the absolute value of the minimum gradient between two
defined locations.”
This is an old left over from a removed requirement form Baseline 2.
“3.11.10.3
Between two defined locations, e.g. A and B in the
above figure, the trackside shall provide the lowest value of the
gradient (taking the sign into account) found between these two
locations.”
This requirement was deleted by CR595 (Brake curve calculation).
Furthermore is the text ambiguous because the gradient value G_A
has no sign. For B2 the text “(taking the sign into account)” should
have been added.
Supporting document(s) for
problem/need description
Agreed Solution
Modify SUBSET-026 v3.4.0 as follows:
Modify 7.4.2.6, row "Description" as follows:
Delete the clauses. ”D_GRADIENT gives the distance to the next
change of the gradient value. The gradient value is the minimum
gradient for the given distance.”
Modify 7.5.1.37as follows:
Row "name", replace "Safe gradient" with "Gradient"
Row "Description", Replace "minimum" with"engineered"
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
2014-09-18 01:20:49 PM
2014-12-09 12:42:52 PM
1255
Impossibility to transmit unknown values in the message “Additional
data”
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
SUBSET-027
Page 60 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Error/Enhancement
Problem/Need description
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Identification number
Headline
Reference Baseline Release
Documents and/or References
Error/Enhancement
Problem/Need description
Error
The variables in the message “ADDITIONAL DATA” have a
definition as per chapter 7 of the Subset-026 (see section 4.2.4.24 in
the Subset-027).
These definitions do not contain the possibility to indicate that the
value of these variables is unknown.
However this message “ADDITIONAL DATA” gathers data which
can be acquired at different points in time. It can therefore happen
that when the value of a data item has to be recorded the value of
some other data is not yet known.
For instance, in the SoM procedure, the train running number could
still be unknown when the recording of the RBC data entered by the
driver has to take place.
Depending on the context, the value of some data will even not be
acquired at all.
For instance, the driver may change the value of the reduced
adhesion while operating in level 1. The new value of the reduced
adhesion has to be recorded via the variable “M_ADHESION” of the
message “ADDITIONAL DATA”. But the value of variables such as
“NID_MN” or the RBC data related variables may be unknown (onboard not fitted with Mobile Terminals i.e. not capable to operate in
level 2/3) and this message does not allow to express that.
Modify SUBSET-027 v3.1.0 as described in the attachment
"ERA_solution_for_CR1255_240215.docx"
ERA_solution_for_CR1255_240215.docx
2014-11-10 04:23:07 PM
2015-03-17 07:51:06 PM
1260
Inconsistent set of clauses regarding the service brake interface in
SH mode
Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)
SUBSET-026
Error
The service brake interface is defined as train data which could be
understood as having to be acquired before starting a mission. This
seems to be inconsistent for the case of SH mode, i.e. the SRS
clause 3.13.2.2.7.1 specifies that “The on-board shall be configured
to define whether the service brake command is implemented or not,
i.e. whether a service brake interface is implemented to command a
full service brake effort.”.
This clause defines a configuration item of the ETCS on-board
which is independent of the ETCS mode. In particular, a train in SH
mode will know by configuration whether the service brake interface
is implemented or not.
In addition, the SRS clauses 3.13.2.2.1.1 and 3.13.2.2.1.2 specify
that “service brake interface” is acquired as Train Data.
But the clause 3.13.2.2.1.2 refers to clause 3.18.3.2 which is about
Train Data that shall be acquired by the ERTMS/ETCS on-board
equipment of a leading engine before starting a mission.
SRS section 5.4.6 however states that entry to mode SH is not
starting a mission.
Page 61 of 62
PROJECT PLAN No. ETCS B3 Release 2 \ PPL V 1.13
Besides SRS section 4.10 specifies that train data are to be
revalidated when entering in SH mode.
All these clauses taken together do not read consistent for the
modes where no mission is started.
Supporting document(s) for
problem/need description
Agreed Solution
Supporting document(s) for
agreed solution
Date of Submission
Last modification date
Modify SUBSET-023 v3.1.0, SUBSET-026 v3.4.0 and SUBSET-027
v3.1.0 as described in attachment
"ERA_Solution_for_CR1260_090315.docx"
ERA_Solution_for_CR1260_090315.docx
2014-11-10 04:42:59 PM
2015-03-17 07:53:51 PM
The attachments from the CRs can be found in the following file:
Page 62 of 62