Identification number 0239State Presented_to_ECHeadline Train data on TIUImpacted System ETCSReference Baseline Release 2.3.0 (TSI CCS annex A modified by decision 2007/153/EC)Documents and/or References SUBSET 026-3, V2.3.0, 3.18.3.2, 3.19

SUBSET 026-5, V2.3.0, 5.4.3.2SUBSET 034, V2.0.0, -

Error/Enhancement ErrorProblem/Need description 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 descriptionSolution Proposal by submitter Bring SRS and TIU FIS in line by adding train data to the TIU FIS.

Add the requirement, that, if existing, data from the TIU is presented to the driver for confirmation, to SRS 3.19

Supporting document(s) for solution proposalAgreed 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 solutionJustification/Discussion for Solution

Accepted. Modify 3.18.3.2.1 to read:“The ERTMS/ETCS on-board equipment shall acquire train data from driver input or from ERTMS/ETCS external sources (i.e. from the train interface).” Add new clause 3.18.3.2.2 to read:“It shall be possible to transmit the train running number from the RBC” 28/06/05 (HK): Change regards clause 3.18.3.2.2 is superseded by CR 500 decision

Remark: The requirement to confirm train data from an external system depends if the source is safe. We think such a requirement is obvious and not needed to be added. For the need to upgrade the FIS TIU : accepted, however not yet scheduled

ERA 16/01/08

Change regards clause 3.18.3.2.1 is also superseded by CR500 decision.

UNISIG 11/07/12Modify Subset-034 v3.0.0 §2.6.2.1 to read: "The train data information is an input that makes the ERTMS/ETCS on-board equipment able to determine the values for the train data listed in §3.18.3.2 of [1], for those data that are acquired from external sources."

EUG 30-08-2012Agreed

ERA 07/04/14The term "for those data that are acquired from external sources" does not give any clue on which data can be acquired from external sources. The exhaustive list of train data items that can be changed by external sources shall be clearly specified.

UNISIG 29/08/14See attachement «Updated solution proposal for CR239 -20140829.docx» for an updated solution proposal.

ERA 01/09/14The solution proposal dated 29/08/14 is agreed. In addition we propose to fix a small editorial inconsistency between the clause 3.13.2.2.6.1 and the clauses 3.13.2.2.6.4, 3.13.2.2.7.1&2 and 3.13.2.2.8.1: 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".

EUG 05-09-2014Proposal from UNISIG with ERA improvement accepted.

ERA 18/03/15As a result of CR1260, the UNISIG solution proposal dated 29/08/14 and amended by ERA on 01/09/14 shall be revised as follows:Modifications to SUBSET-026 v3.4.0- 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".Modifications to SUBSET-034 v3.1.0 - 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.”

EUG 30-03-2015Updated ERA proposal 18/03 agreed.

UNISIG 08/04/15Updated ERA proposal 18/03 agreed.

Supporting document(s) for Justification/Discussion for Solution

Updated solution proposal for CR239 -20140829.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

EEIG (ERTMS users group)

Contact person name R. DijkmanContact Person e-mail adress rdijkman@ertms.beEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number EEIG 070List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponement See statement by the CR1136 submitter :"Due to the variety of ways

this information can be entered via the train interface, there is no easy fit for purpose solution".It is confirmed that such fit for purpose solution cannot be found in the frame of the baseline 3.

Superseding CRList of superseded CRs Date of Submission 2008-01-09 07:15:20 PMLast modification date 2016-01-06 04:09:59 PM

Identification number 0299State Presented_to_ECHeadline Version compatibility checkImpacted System ETCSReference Baseline Release 2.3.0 (TSI CCS annex A modified by decision 2007/153/EC)Documents and/or References Subset 026-3, V2.3.0, 3.5.3.12, 3.17.3.7Error/Enhancement EnhancementProblem/Need description 1) SRS 3.5.3.12 says that the ERTMS system version check when

establishing a communication session is foreseen only in case the on-board initiates the session. From DB s point of view, there is always a need to verify the compatibility of the system versions, also in the case the RBC is the initiator. 2) Furthermore, a possibility is necessary for the RBC to enquire the ERTMS system versions which the on-board is able to work with. If a

train e.g. has to be rerouted, it must be possible to check in advance whether the onboard is able to run on that line. This should be possible independent from the train data (thinking e.g. of sleeping engines). 3) SRS 3.17.2.2 defines the system version as a number X.Y, where X represents incompatible versions and Y compatible versions. The use of the X part is clear, but the use of the Y part is not clear. For what purpose is it included in the SRS

Supporting document(s) for problem/need descriptionSolution Proposal by submitter 1) Modify 3.5.3.10 / 3.5.3.12 and/or the messages 32 and 38 in such

a way that the ERTMS system version check is also performed when the communication session is initiated by RBC.2) Add a new packet to the specification train ( track, using N ITER and M VERSION to report all versions the onboard is able to work with, which is sent every time a session to an RBC is established (also in SL mode etc).3) Clarify the use of the Y part in the system version.

Supporting document(s) for solution proposalAgreed Solution Modify SUBSET-023 v3.1.0, SUBSET-026 v3.4.0, SUBSET-039

v3.1.0 and SUBSET-104 v3.2.0 as described in the attachment "ERA_solution_for_CR299_121215.docx"

Supporting document(s) for agreed solution

ERA_solution_for_CR299_121215.docx

Justification/Discussion for Solution

1) The version check in this case is not necessary again, because such as situation is always preceded by the train calling the RBC (e.g., sleeping unit passing a level border, or RBC has lost contact to all trains) 2) Generally accepted, UNISIG to work out a solution, also covering fitted levels, STMs, options, SC to agree (new function) 3) Accepted, UNISIG to work out proposal for version management HK 12.1.05: Item 3 is now covered by new Subset 104 (Alstom) plus the related changes to SRS chapter 3.17

17/02/05 EEIG/ UNISIG: Reporting of available system versions by on-board is included into system version 3.0.0 SG 28/04/05 Accepted solution covers 2), see attachment: Solution_Proposal_CR_299 28.4.05.doc UNISIG 5/10/05 (HK) regards 3) System version management was last discussed in SG meeting 17 to 19 Jan 05. The conclusions were the following: - Comments from the railways were received regards the proposed approach. See attachment: Railways remarks on the UNISIG proposal for Version Management with SG reply included. Note: The attached document (file ref: 04c704 0b-

SG_clean.doc) is the cleaned-up version which was delivered to the railways. Attached are the actual system version management related documents : SUBSET-104_v002.ZIP, System_version_mngt_SRSchapters_mods_180205.doc Note: The accepted solution regards item 2) may have to be changed again depending on the decision agreed with the railways for the system version management 27/01/06 (HK) Email .A. Hougardy : Please find attached the refreshed attachment to CR299 (see attachment: System_version_mngt_CR299_270106.doc), in the light of all the CR decisions taken since dec 04. For clarity reasons, I have re-inserted the decision regarding item 2). 17/10/06 (HK) CR rejected (superseded). Issues 2) and 3) are now covered by CR 757 EEIG 21/11/06: If we put everything together in one big CR we are not able to decide independently on the different issues. Since item 2 of U299 has nothing to do with the general principle of the version management (which could very well be agreed without item 2 of U299 and which we need by definition in the basket for SRS300) we strongly prefer to keep item 2 in U299 (which we then can decide independently to be in or out of the basket for 300). All the rest can go to U757. UNISIG 12/12/06: Item 2 to be kept in this CR (see attachment "Solution_Proposal_CR_299 28.4.05.doc")

ERA 29/05/15See attachment "ERA_solution_proposal_for_CR299_290515.docx" for a detailed solution proposal addressing items 2) and 3) of the problem/need description, but above all addressing the need to incorporate the CR1229 as a compatible CR into the B3R2 release, which leads to a system version number Y increment deserving itself some clarifications.

UNISIG 03/06/15See attachment "ERA_solution_proposal_for_CR299_290515-SG.docx" for UNISIG comments on solution posted by ERA on 29/05/15.

EECT 10/06/15The UNISIG comments 03/06/15 are discussed, see EECT tags inserted in the Word comments in the attachment "ERA_solution_proposal_for_CR299_EECT100615.docx".In particular: - It is agreed to introduce the system versions supported by the on-board in the RBC/RBC pre-announcement message as proposed by UNISIG. - ERA clarifies that to deal with all the modifications related to the introduction of a Y change in the system version, the CR299 should not be used but rather an ad-hoc CR, which will be created to this effect. - UNISIG considers that, even with the CR 299 current proposal, the CR1129 remains incompatible because there will be no clue in the B3R2 specifications about the fact that there is no age speed measurement requirement for 2.0 trains. ERA replies that to which extent a trackside engineering should take into account the behaviour of the on-board which is specified in an older release of the specifications goes largely beyond the scope of this CR. However, considering that a trackside which should care about the behaviour of a compatible on-board contradicts a bit the intuitive notion of compatibility, it is agreed to reflect on an engineering rule in SUBSET-040 for RBCs hosting trains not supporting the 2.1 version and that consequently cannot rely on the speed measurement age.

ERA 30/06/15See updated solution proposal (parts highlighted in blue and new section for SUBSET-039) in attachment "ERA_solution_proposal_for_CR299_300615.docx".Regarding the UNISIG reservation about the CR1129 compatibility, after a second thought we consider as inappropriate the suggested engineering rule in SUBSET-040, for the following reasons: - the compatibility of a new baseline results from the packaging of CRs, whose compatibility is individually assessed according to SUBSET-104 section 5.3. A careful reading of this latter can only lead to the conclusion that the CR1129 is compatible. - actually the CR299 just makes the enhancement to guarantee the age of the speed measurement exploitable by the trackside - unlike what was considered during the EECT 10/06/15, we rather think that the trackside engineering cannot not take into consideration what are the missing functions of the trains operated with a lower system version number Y, within the X version operated by the trackside - the concerned missing functions or rather the list of all the enhancement CRs that have led to Y increments should be found at most in the CCS TSI application guide

EECT 08/07/15UNISIG has the following comments on the reasons given by ERA (30/06/15) about the compatibility of CR1229: 1) Regarding first reason (“the compatibility of a new baseline results from the packaging of CRs…”): UNISIG doesn’t understand what ERA is trying to say here. Is ERA saying that CR1229 – when “individually assessed” – is a compatible CR? In other words, is ERA saying that it is compatible even without CR299? If so, on what

basis?The information that speed measurement of older trains may differ is relevant for safety. Without that information stated explicitly the solution is not compatible. 2) Regarding second reason (“actually the CR299 just makes the enhancement…”): ERA seems to consider the modifications brought by CR1229 as “minor” modifications. Probably that this is linked with ERA’s view that this CR is a compatible CR. In our opinion, these modifications can lead to safety consequences if the trackside is not "aware" that the CR modification is not implemented in the on-board.Regarding the exploitability, as long as not all the trains have implemented the CR, the full benefit of this CR cannot be taken since the trackside has still to take measures for the trains that do not have implemented the CR. 3) Regarding third reason (“unlike what was considered during the EECT 10/06/15…”): The need to do this should be clear from the set of specifications against which the trackside will be certified i.e. the fact that this function does not apply to system version 2.0 and lower should be found in the B3 R2 set of specifications (see next comment). 4) Regarding fourth reason (“the concerned missing functions or…”): According to Subset-104 6.1.3.2, “The composition of the envelope of X versions, complemented by the possible Y versions, shall be specified in the SRS. All the requirements listed in the TSI annex A documents shall by default be applicable to all the legally operated system versions, unless otherwise specified.”The reader of the B3 R2 set of specifications – e.g. a trackside designer – would therefore be justified in assuming that the requirement for the age of the reported speed applies to all system versions within the envelope of legally operated system versions. Why, therefore, should an RBC developer make exceptions for trains supporting system versions lower than 2.1?The solution can only be compatible if the information about differing speed measurements is stated explicitly in a mandatory document (like Subset-40). Without knowing the different speed measurements the exchange of system versions would be a useless function.

Concerning the UNISIG remarks 1&2: ERA considers indeed that the CR299 and CR 1229 are just enablers for a non-ETCS functionality that uses the age of the speed measurement. ERA also recalls that assessing the compatibility of CRs should only be regarded with the perspective of the ETCS functions. Therefore for the particular case of CR1229, the answer to the SUBSET-104 question “Can a train without the CR run a normal service on any trackside infrastructure where the CR is implemented?” should be “N/A” because the CR1229 consists of a pure on-board change. This can be compared with many Q2 answers in the frame of the BCA exercise. UNISIG strongly objects to ERA’s view highlighting that it is clear from the problem description that CR1229 is requested for the implementation of non-ETCS functions: the problem description of CR1229 is exclusively about the activation of LX barriers in the Netherlands. It sounds therefore inconsistent to include such a CR in the B3 R2 basket and then leave apart the non-ETCS functions when assessing the compatibility of this CR.

Concerning the UNISIG remark 3: ERA underlines that unlike the

system versions differing by X, as soon as several Y versions are coexisting within a given X system version by definition on-boards are authorised to run without some of the functions specified in the latest version. It is therefore ineluctable that an IM should take into account all the sets of specifications previously published against which on-boards that are allowed to operate can be certified. ERA rather considers that the list of new functional changes (enhancement CRs) resulting in each Y increment should be listed in the TSI Application Guide.EUG indicates that they will investigate within the IMs (EIM) whether this is sufficient.Post meeting note: The issue was discussed in EIM. Although it was a surprise for some IMs, it was very clear for other IMs that there is always the need to assess if their trackside concept is impacted when on-boards with different versions will come to this trackside.

Concerning the U remark 4: ERA agrees to amend properly the SUBSET-104 clause 6.1.3.2 as follows: “The composition of the envelope of X versions, complemented by the possible Y versions, shall be specified in the SRS. All the requirements listed in the TSI annex A documents shall by default be applicable regardless of the operated system version, unless otherwise specified".

UNISIG has also the following comment on ERA solution proposal posted on 30/06/15 and more precisely regarding the System Versions in the Pre-Announcement in Subset-39: In case a HOV RBC = 2.1 talks to an ACC RBC = 2.1 but the train registered to HOV RBC was B3MR1 (not having reported its system versions), wouldn’t then the System Versions in the Pre-Announcement have to be an optional packet?The comment is accepted, i.e. in SUBSET-039 section 5.2.1 no new line has to be added but the existing line “optional packet” modified to read “optional packets” and to add packet 2 together with the packet 3 in the rightmost column.

ERA 15/07/15See attachment "ERA_solution_proposal_for_CR299_150715.docx" for the updated solution proposal according to the two modifications agreed during the EECT meeting 08/07/15.

EUG 01-09-2015The CR299 related modifications are agreed. The CR1262 related modification (deleting P3) is not agreed because CR1262 is still in discussion. (It would have been better not to mix the modification of CR1262 into the CR299 solution proposal.)

UNISIG 01/09/15See file in the attached zip archive "CR299 U2015-09-01" for the UNISIG comments to the ERA solution proposal 15/07/15.

EECT 08/09/15The UNISIG comments (01/09/15) on the updated ERA solution proposal 15/07/15 are discussed, see replies tagged “EECT080915” in the Word comments inside the attachment "ERA_solution_proposal_for_CR299_EECT080915.docx".

ERA 24/09/15See parts highlighted in blue in the attachment "ERA_solution_proposal_for_CR299_240915.docx", resulting from the review (08/09/15) of the UNISIG comments.

EUG 01-10-2015We agree with the blue modifications made by ERA, with one very minor remark. In the first blue section the paragraph number should be 3.15.1.2.1.We therefore repeat our previous statement that only the CR299 related part is agreed. There is no reason at all to mix a potential outcome of a CR still in discussion with this CR299. That is not an example of proper CR management.

UNISIG 02/10/15UNISIG has a major comment on the solution proposal posted by ERA on 24/09/15: The change in Subset-039 clauses 6.x.1.1 and 6.x.3.1 proposed in the frame of action 13.01 does not work. According to part highlighted in blue in 6.x.1.1, the exception to 5.2.1 (Pre-Announcement message) does only apply for the handing over RBC, but not for the accepting RBC (see text “RBC operating with system version X.Y = 2.1, which is handing over a train fitted with an on-board equipment whose highest supported system version X.Y = 2.0”). The accepting RBC will still apply 5.2.1 and will therefore consider the message not containing packet 2 as inconsistent and reject it.In addition, unlike the case of the packet 11, the Accepting RBC cannot know from the value of a variable in the message (directly in the message, not in packet 2) whether packet 2 will be part of the message or not. Here the accepting RBC would have to check the content of the packet to know whether the exception applies that packet 2 is not contained.

Based on the above, UNISIG proposes to define the packet 2 as an optional packet of “Pre-announcement” message in 5.2.1 and add a requirement on the Handing Over RBC in S-039 section 4.5.1 specifying that it is mandatory to forward packet 2 in the Pre-Announcement if it is available. SRS 3.15.1.2.1b) would list the supported system versions as optional data.It would be added in SRS section 6.5.1.2 that the bullet “The system versions supported by the on-board equipment” in clause 3.15.1.2.1 b) shall not apply.SRS clause 6.5.2.1.1.1 would be modified to read “This section is also applicable for trackside infrastructures with RBCs/RIUs certified to the system version number X.Y = 2.0 or for trackside infrastructures with RBCs certified to the system version number X.Y = 2.1 communicating with RBCs certified to the system version number X.Y = 1.0, 1.1 or 2.0.”SRS clause 6.5.2.2.1 would be modified to read “For RBCs certified to the system version number 2.0 and for RBCs certified to the system version number 2.1 communicating with an RBC certified to the system version number 1.0, 1.1 or 2.0, the bullet “The system versions supported by the on-board equipment” in clause 3.15.1.2.1 b) shall not apply”.Subset-039 clause 6.x.1.1 “This section applies to an RBC operating

with system version X.Y = 2.0 and to an RBC operating with system version X.Y = 2.1 exchanging information with an RBC X.Y = 1.0, 1.1 or 2.0.”

U has additional comments on the solution proposal posted by ERA on 24/09/15. They appear as Word comments in attachment “ERA_solution_proposal_for_CR299_240915-U.docx”.

EECT 07/10/15Concerning their major comment (02/10/15), UNISIG considers that even if the section 6.x.1.1 would also include the case of an RBC 2.1 accepting a train 2.0 from a RBC 2.1, the fact that 6.x.3.1 is written as an exception can be read, from the accepting RBC standpoint, as if the pre-announcement specified in 6.x3.1 could completely substitute the pre-announcement in 5.2.1.Even though ERA argues that in practice, the accepting RBC 2.1 must be able to handle the pre-announcement with or without the packet 2, regardless it is specified only in 5.2.1 as an optional packet or both in 5.2.1 and 6.x.3.1, it is agreed to not consider in 6.x.1.1 the case of the handing over of a train 2.0 between two RBCs 2.1. However it is also agreed that the term “optional” in the pre-announcement message is not at all appropriate, since it is confirmed that the sending of the packet 2 is mandatory for a handing over RBC 2.1 (except if this RBC hands over a train 2.0). In other terms the RBC 2.1 cannot choose to discard the packet 2 when received from on-board. The same also goes for packet 5.Concerning the other UNISIG remarks/suggestions (02/10 /15) about the SRS clause 3.15.1.2.1 b) and SRS chapter 6 related clauses, they are all rejected because these requirements are only valid for HO RBCs.Conclusion: the CR is closed with the modifications agreed during the meeting, i.e. those ones resulting from the above and the ones resulting from the other comments embedded in the attachment "ERA_solution_proposal_for_CR299_240915-U.docx".Post meeting note: the terms “additional” (replacing “optional”) and “if available” need also to be added in the pre-announcement message in 6.x.3.1.See parts highlighted in blue in the attachment "ERA_solution_proposal_for_CR299_EECT081015.docx" for details.

EECT 08/12/15The following amendments to the solution 08/10/15 are agreed.SUBSET-026 part:- wrong numbering: 3.17.2.8 (2nd occurrence) shall be 3.17.2.9 and 3.17.2.9 shall be 3.17.2.9.1- the reference to CR299 (in hidden text) is missing in 6.5.1.6.6.5- The last 2 clauses shall be numbered 6.6.4.1.1 and 6.6.4.1.2- 6.5.2.3.3.3: The field numbers should be 1 to 5 instead of 6 to 10- the new clause 6.6.3.4.1.1 must make reference to 3.5.3.7 d) 1st bullet instead of to 3.5.3.8 a) which has been moved as per CR1117.- 8.4.4.4.7.1 to be renumbered to 8.4.4.7.1- the deletion of 8.4.4.4.3 is to be withdrawn, since it is covered by CR1262SUBSET-104 part:- 6.1.3.3: since exceptions applicable to a RBC 2.1 are introduced, the part between brackets should have disappeared to keep the

sentence general enough.

See parts highlighted in blue in the attachment "ERA_solution_for_CR299_121215.docx" in the field "Agreed Solution"

Supporting document(s) for Justification/Discussion for Solution

Solution_Proposal_CR_299 28.4.05.docSUBSET-104_v002.ZIPSystem_version_mngt_SRSchapters_mods_180205.doc04c704 0b SG-SC_clean.docSystem_version_mngt_CR299_270106.docERA_solution_proposal_for_CR299_290515.docxERA_solution_proposal_for_CR299_290515-SG.docxERA_solution_proposal_for_CR299_EECT100615.docxERA_solution_proposal_for_CR299_300615.docxERA_solution_proposal_for_CR299_150715.docxCR299 U2015-09-01.zipERA_solution_proposal_for_CR299_EECT080915.docxERA_solution_proposal_for_CR299_240915.docxERA_solution_proposal_for_CR299_240915-U.docxERA_solution_proposal_for_CR299_EECT081015.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

EEIG (ERTMS users group)

Contact person name R. DijkmanContact Person e-mail adress rdijkman@ertms.beEndorsed by Recognised Organisation(s)Project Information Berlin-Leipzig (2007)Submitter Reference Number EEIG 088List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassification

Only item 2 (functional enhancement) has been kept in this CR, while item 3 is covered by CR 757

Reason for rejectionReason for postponement Control Group decision 24/05/07Superseding CRList of superseded CRs Date of Submission 2007-08-25 01:39:53 PMLast modification date 2016-01-06 04:10:50 PM

Identification number 0539State Presented_to_ECHeadline Set speed indication for driverImpacted System ETCSReference Baseline Release 2.3.0 (TSI CCS annex A modified by decision 2007/153/EC)Documents and/or References TS50459-2 §6.1.2.6 and SUBSET-034

Error/Enhancement EnhancementProblem/Need description 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 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 descriptionSolution Proposal by submitter A simple generic approach is required providing the following

optional functional interfaces with the onboard ETCS: ETCS output of odometry information (instantaneous train speed* and current position). Necessary to eliminate risk of control conflict between the ETCS and the set speed controller systems that might otherwise result from using different odometry sources. ETCS input to onboard ETCS to allow the selected speed controlled by the set speed controller, and its activation status (engaged/disengaged), to be mirrored on ETCS DMI speedometer scale.* ETCS output of the characteristic deceleration profile (acceleration as a function of speed (a(v))) corresponding to specific train data (preconfigured train data or driver entered data) ETCS output of the gradient and speed profile (MRSP) associated with MAs received from the trackside ETCS output of the brake indication point (train approaching a braking section) The necessary interfaces should be added as an optional requirement in TIU FIS, SUBSET-034. Note: As the proposed requirements are optional, it is permissible for a reduced set of functional interfaces to be implemented as necessary to support the needs of particular set-speed control systems. For example, simple fixed speed controllers, without dynamic speed profile control, may require only the odometry instantaneous speed output and DMI input interfaces as indicated (*). Such controllers require manual selection of the function at each step in the speed profile.

Supporting document(s) for solution proposal

EEIG096 210704 annex.doc

Agreed Solution 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_101215.docx"

Supporting document(s) for agreed solution

Solution_for_CR539_101215.docx

Justification/Discussion for Solution

22/10/04 New function, postponed HK 26.10.04: SC (L. Abel) informed 17/02/05 EEIG/ UNISIG:

Functionality requested by this CR is not included into system version 3.0.0

EUG 24-02-2014Following the discussions last year in the context of the maintenance of the baseline 3 specifications, EUG has sent in August 2013 to ERA and UNISIG an updated motivation paper plus solution proposal. See attachment "CR539 motivation 20130806".

UNISIG 29/08/14See attachment "Unisig_SG_COM_CR539 - 20140829.doc" for UNISIG comments on EUG solution proposal posted on 24/02/2014.

ERA 01/09/14The UNISIG comments posted on 29/08/14 are endorsed, which in particular make the solution proposal not feasible for the DMI part. In addition we wonder if some interactions with the new ATO interface could appear.

EUG 22-09-2014See our answer to the UNISIG comments in attachment "Unisig_SG_COM_CR539 - 20140829-EUG". The accepted comments are included in attachment "CR539 solution proposal v5". Note that the modifications to the version which was reviewed by UNISIG are marked in green.We propose to discuss the ERA question regarding ATO in the context of the CR1238.

UNISIG 26/09/14See attachment "Unisig_SG_COM_CR539 - 20140924.doc" for UNISIG comments on EUG solution proposal v5.

ERA 30/09/14See attachment "" for three other comments, which come in addition to the UNISIG ones posted on 26/09/14

EECT 08/10/14All the UNISIG (22/09/14) and ERA (30/09/14) comments have been addressed, see consolidated review shee in attachment "CR539_review sheet_EECT_081014.docx".Only one comment is still marked "D" for what regards the space left between the set speed object and both the hook and the speed pointer. EUG to choose between the current proposal (1 cell only) and a counter proposal consisting to increase the space left to 2 cells by reducing the size of the set speed circle to 8 cells and to update according to this choice and to the agreed replies to all the other review comments.

EUG 22-10-2014See the attachment "CR539 solution proposal v6" for the updated solution proposal according to the conclusions of the EECT 08-10-2014 with the following remarks.1) As agreed this week by email the impact on Subset-027 is not included.2) The size of the set speed object has been discussed already in

the first version of the proposal with Jochen Vorderegger (ergonomic expert) and Rainer Eschlbeck (operational expert), both also DMI experts. The size of 8 or 10 cells were both considered in that phase and a clear preference was expressed for 10 cells. Following the remarks from the October EECT a double check with the same experts was made of the "worst case" situation, i.e. CSG/hook and speed pointer both white and speed pointer, set speed object, hook all in line. The space of 1 cell between the set speed object and the hook or speed pointer was not considered to create any problem for the driver. The orginal choice of 10 cells was therefore confirmed and retained in the solution proposal.

ERA 27/10/14See attachment "ERA_solution_proposal_for_CR539_SS-027.docx" for the necessary modifications to the SUBSET-027.Note that unlike what was recorded during the EECT meeting 08/10/14, we opted for a much more straightforward specification, consisting in DMI based triggering events for the message (same as for LSSMA) to be forwarded to the onboard recording device.

EECT 04/11/14The solution proposal formed by the EUG proposal 22/10/14 and the ERA proposal 27/10/14 for SUBSET-027 is agreed as a whole. See attachment "Solution_for_CR539_041114.docx" for details.

EECT 08/12/15The following amendments to the solution 04/11/15 are agreed:

- In the DMI spec part, the reference to the blue figure 28 is not in line with the document structure. Each section gives its own area(s) even if it repeats the same area(s) as in other sections (e.g. 8.2.3.5 for track conditions and 8.2.3.8 for LX not protected) => reuse figure 28 in the context of section 8.2.3.9 for set speed numbered figure 71b - The reference to Subset-026 clause 3.15.11 in the added line to table 1 “SRS references” of Subset-034 is wrong. This reference is to be replaced with a reference to Subset-026 clause 4.7.2 - In new clause 2.5.5.1.1 of Subset-034, the term “onboard” is to be replaced by “on-board”

See attachment "Solution_for_CR539_101215.docx" in the field "Agreed Solution".

Supporting document(s) for Justification/Discussion for Solution

CR539 motivation 20130806.zipUnisig_SG_COM_CR539 - 20140829.docUnisig_SG_COM_CR539 - 20140829-EUG.docCR539 solution proposal v5.docxUnisig_SG_COM_CR539 - 20140924.docCR539_review sheet_ERA300914.docxCR539_review sheet_EECT_081014.docxCR539 solution proposal v6.docxERA_solution_proposal_for_CR539_SS-027.docxSolution_for_CR539_041114.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment Benefits

Economic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

EEIG (ERTMS users group)

Contact person name R. DijkmanContact Person e-mail adress rdijkman@ertms.beEndorsed by Recognised Organisation(s)Project Information Not providedSubmitter Reference Number EEIG096List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponement See decision EEIG/UNISIG 17/02/05Superseding CRList of superseded CRs Date of Submission 2008-01-28 05:49:17 PMLast modification date 2016-01-06 04:10:50 PM

Identification number 0740State Presented_to_ECHeadline Unclear requirements concerning functions active in L2/L3 onlyImpacted System ETCSReference Baseline Release Baseline 3 (1st consolidation release 02/2010)Documents and/or References Subset-026-3 version 3.1.0, 4.5.2 Error/Enhancement ErrorProblem/Need description 1. The SRS does not describe which functions are active in L2/3

only.A remark in brackets appears in table 4.5.2 for some functions (e.g. check radio safe connection), but this is not applied comprehensively. For example “Manage RBC/RBC handover” or “Manage TAF Request” should be applied in L2/3 only but this is not stated.Other functions, for example text messages with a request to report driver acknowledgement to the RBC, are interpreted as a pure L2/3 function, but are not mentioned in the active function table at all.2. Which ongoing actions, triggered by a L2/3 function, are continued after leaving level L2/3?

Supporting document(s) for problem/need descriptionSolution Proposal by submitterSupporting document(s) for solution proposalAgreed Solution Modify SUBSET-026 v3.4.0 as follows:

Modify 4.4.11.3.1 to read “The ERTMS/ETCS on-board equipment supervises a ceiling speed, a SR distance if finite and, if available, a list of balises.”

Modify table 4.5.2 (active functions) as follows:Add “(only level 2/3)” in lines “Request MA on track description deletion”, “Handle Co-operative MA revocation”, “Manage RBC/RBC handover”, “Manage Track Ahead Free Request” and “Report train position when train front/rear passes a RBC/RBC border”.

Supporting document(s) for agreed solutionJustification/Discussion for Solution

UNISIG 21/11/14Regarding item 1 of the problem description, the following modification to Subset-026 v3.4.0 is proposed : add “(only level 2/3)” in lines “Request MA on track description deletion”, “Handle Co-operative MA revocation”, “Manage RBC/RBC handover” and “Manage Track Ahead Free Request” of the active functions table in 4.5.2 . Note: SRS clause 4.4.11.3.1 suggests that the list of balises in SR is only supervised in level 2/3 (see "and if level 2/3, might also supervise a list of balises" in this clause). Even if the list of balises in SR can only be received from an RBC and is only accepted by an on-board in levels 2 and 3, the SG understanding is that an-going supervision of a list of balises in SR in level 2/3 will continue if the ETCS on-board executes a transition to level 1. It this undertanding is correct, the clause 4.4.11.3.1 should be amended to reflect that the supervision of the list of balises in SR is not limited to levels 2 and 3.

Regarding item 2 of the problem description: the resolution of this item cannot be decoupled from the resolution of item 2 of CR1021. These two items are about the general issue of the termination of actions related to a function which is no more active. UNISIG therefore proposes to prepare a solution proposal which addresses this general issue. UNISIG plans to be ready with this solution proposal at the latest one week before the March EECT meeting (first EECT meeting in which the CR1021 will be discussed according to current version of the project plan).

EUG 28-11-2014We agree with UNISIG that the statement "(only level 2/3)" in table 4.5.2 should be used consistently and not only for a few L2/L3 functions. We would therefore agree with the UNISIG proposals, but we are not sure if they are exhaustive. E.g. for "report train position when train front/rear passes a RBC/RBC border" we would assume that the statement "L2/L3 only" would apply here also. Please clarify.Regarding 4.4.11.3.1 we do not see any justification in the SRS that the supervision of the list of balises in SR should stop when the level changes to something other than L2/L3. Therefore we agree with UNISIG that 4.4.11.3.1 should be amended to reflect this in a correct way.

Regarding item 2 we wait the solution proposal.

EECT 03/12/14Item 1: UNISIG confirms that the check was exhaustive and the above mentioned line was considered as covered by the line “Manage RBC/RBC handover”. In spite of this justification, it is agreed to mark this line with “(level 2/3 only)”.

Moreover, it is confirmed that the amendment to clause 4.4.11.3.1 needs to be added as well, considering that the supervision of the list of BG’s does not stop when a transition to a level other than 2/3 occurs.

Item 2: it is agreed to link it to CR1021.

UNISIG 17/12/14Item 1: Based on EECT 03/12/14 conclusions, it is proposed to modify Subset-026 v3.4.0 as follows (this new solution proposal replaces the previous solution proposal) :

Add “(only level 2/3)” in lines “Request MA on track description deletion”, “Handle Co-operative MA revocation”, “Manage RBC/RBC handover”, “Manage Track Ahead Free Request” and “Report train position when train front/rear passes a RBC/RBC border” of the active functions table in 4.5.2 .

Modify 4.4.11.3.1 to read “The ERTMS/ETCS on-board equipment supervises a ceiling speed, a SR distance if finite and, if available, a list of balises.”

EECT 13/01/15The item 1 update (see UNISIG proposal 17/12/14) is agreed.Regarding the item 2, the Agency remarks that it might be not fully covered by CR1021, since so far this latter only relates to the brake command. The closure of the CR (item 2) will therefore depend on how develops the solution proposal for CR1021.

EECT 07/10/15Further to the CR1021 removal from the B3R2, it is agreed to de-scope item 2 and to close the CR with only the already agreed solution for the item1.As a result, the Item 2 of the CR 0740 will be either moved to a new CR or incorporated into CR1021 so as to extend its scope.

Supporting document(s) for Justification/Discussion for SolutionPreliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name L. RepettiContact Person e-mail adress luca.repetti@ansaldo-sts.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number 740

List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponement Only very minor editorial improvement (to be checked), nearly a non

CRSuperseding CRList of superseded CRs Date of Submission 2010-09-12 07:50:13 PMLast modification date 2016-01-06 04:10:50 PM

Identification number 0741State Presented_to_ECHeadline Packet data transmission for ETCSImpacted System ETCS&GSM-RReference Baseline Release 2.3.0 (TSI CCS annex A modified by decision 2007/153/EC)Documents and/or References -Error/Enhancement EnhancementProblem/Need description The frequency band allocated for Railway use for GSM-R is limited

to 4MHz. This means that 19 frequencies are available in most countries, providing a limited number of circuit switched traffic channels for voice or data transmission.

Sufficient GSM-R capacity is unlikely to be available to support ETCS level 2/3 (in addition to the voice system) in densely trafficked areas because each ETCS onboard unit engaged in a data call (and each voice and non-ETCS data call) will occupy an entire traffic channel.

The current Class 1 specifications do not support the migration to future transmission bearers.

Supporting document(s) for problem/need descriptionSolution Proposal by submitter Upgrade ETCS functional layer to support packet data transmissionSupporting document(s) for solution proposalAgreed Solution Modify SUBSET-037 v3.1.0, EIRENE SRS 15.4.0 and A11T6001

v12.4 as described in the attachments "Subset-037 v316.docx", "gsmr9225-1 11.docx" and "FFFIS for EuroRadio v12.64r11.pdf "

Supporting document(s) for agreed solution

Subset-037 v316.docxFFFIS for EuroRadio v12.64r11.pdfgsmr9225-1 11.docx

Justification/Discussion for Solution

EUG 27-08-2014

The TEN-T project 2011-EU-60013-S, WP9, is on the way to produce specifications for the introduction of packet switched radio communication on the basis of GPRS into the ERTMS specifications.

These specifications are intended to be used for the solution of CR741. At the start of the WP9, the operational and functional needs

of the railways have been described in an internal WP9 document called "ETCS over GPRS principles and functional requirements", reference 11E017.

The introduction of a complex function, like packet switching / GPRS, cannot be achieved by a linear process from functional requirements to a technical solution. An iterative process has taken place in which the document 11E017 has evolved and has been corrected, enhanced and refined during the course of the TEN-T project. Note that 11E017 itself is not intended as part of the solution. It is a working document. Recently the TEN-T project team has produced a version of the 11E017 which is suitable for distribution outside the TEN-T project to document the current status of work. See attachment "11E017-2 ETCS over GPRS principles".

EUG 25-09-2014Minor modifications were made to the "ETCS over GPRS principles and functional requirements" document during the EoG WG meeting 16th/17th September, see revision marks in attachment "11E017-2A ETCS over GPRS principles.docx".

EUG 17-10-2014Gap analysis between BDK implementation and the principles in document 11E017-2A added. See attachment "BDK versus EoG GAP Analysis v3".

ERA 21/10/14See "ETCSoverGPRS_ERAreview_211014.docx" attachment for review comments against version 2A of the the "ETCS over GPRS principles and functional requirements" document. Note that this review sheet only focusses on the principles, excluding any editorial/quality comments.

UNISIG 22/10/14See "Unisig_11E017-2A_COM_SG_141021.doc" attachment for review comments against version 2A of the the "ETCS over GPRS principles and functional requirements" document.

EUG 31-10-2014The answers to the ERA comments are in the attachment "EoG_ERAreview_211014_EoG-WG". Note that the work on the UNISIG comments is still in progress.

EUG 26-11-2014See attachment "11E017-2A comments EUG reply 141125" for the EUG reply to the combined ERA & UNISIG comments.See attachment "BDK versus EoG GAP Analysis v4 141125" for the updated BDK gap analysis.

EECT 01&02/12/14The EoG WG presents slides to justify the two following features (see attachments "Lille_v12_final.pptx" and "Lille_CS_connection_ENIF_testtrack.pptx"): - Prevent the on-board from doing PS -> CS automatic fall back - Need for explicit RBC capability (PS or CS) trackside order, given together with RBC session establishment order

In particular, EUG insists that the rule to engineer the distance between the RBC contact order balise and the RBC entry location (which currently takes into account the 40s connection establishment time specified in SS-037) cannot be reconsidered, e.g. by extending this time because of the PS GPRS attach and PDP context activation tries. Therefore in order to keep this engineering rule unchanged to install the RBC connection balises, it is necessary to send explicit CS/PS order for the RBC.

The replies from the EoG WG to the UNISIG and ERA comments (22/10/14 & 21/10/14 respectively) are exhaustively reviewed (however only the R’s and D’s), see attachment "11E017-2A comments_EECT_141201.doc" for details and various actions. The updated BDK gap analysis (v4 25/11/14) is reviewed too. In particular, it is decided to change the colors of the following cells (column “New Compliance v4”) as follows: - rows 49, 50 and 86: from Green to Red - row 51: from Orange to Red

Amongst the above discussed items, the following outstanding decisions/actions are agreed:

- EDOR vs ETCS APN: the justification why the PDP context activation cannot be part of the PS service set up is the potential use by the on-board of the EDOR to establish a connection to another DNS server than the ETCS one. One possible use of the EDOR is also mentioned, linked to other non harmonised applications (such as maintenance). According to ERA the Etcs Data Only Radio should only be connected to the ETCS DNS server, this latter possibly hosting other ETCS entities than RBCs like e.g. KMC or trackside ATOs.

- It is confirmed that there is no need to trigger the GPRS attach from trackside, this can be done automatically by the ETCS on-board (by sending the relevant AT command to the MT) as soon as the registration to the network is achieved

- CS/PS explicit trackside order for the RBC session establishment orders: the need is acknowledged but it narrowed down to address the case of non PS enabled RBC inside PS areas, for which the rule of the 40s must be kept as it is.

- Since it can double the capacity gain with regard to GPRS (1 to 8 vs 1 to 4), EGPRS will be mandatory onboard

- SoM in PS areas: the EoG WG indicates that this matter is still being discussed, however they are considering moving away from the CS/PS driver data entry to the PS by default option.

- Entry towards a level 2/3 area: a new discrepancy with BDK is discovered (the solution prescribed by BDK is a kind of CS automatic fall back), since EUG considers that no automatic CS fall back should happen even when entering level 2 (i.e. they prefer to have the train tripped instead of this latter pre-empting a CS time

slot)

EUG 30-01-2015This entry contains the results for the following EECT actions:

Action EUG/U (15/01/14) to justify why the EDOR should be used for other applications not connected through the ETCS DNS server and under which conditions (ETCS levels, during an ETCS mission).See for the results from an EUG perspective (not yet reviewed by UNISIG) the document attached “EDOR for other applications v4”.

Action EUG (15/01/14) to come up with a consolidated position with regards to SoMAction EUG (15/01/14) to come up with a consolidated position with regards to entry to level 2/3 degraded caseThese two sections (4.2 and 4.3) have been updated in the 11E017-2A principles document with tracked changes. The 11E017-2A also takes into account other actions in the UNISIG/ERA review sheet. The actions to update the diagrams/figures in the 11E017 have not yet been completed. The ERA/UNISIG review sheet has also been updated. Both these documents are in the zip folder attached "CR741 documents 20150130". This version 2A of the principles has not yet been reviewed by UNISIG.

ERA 13/02/15In order to meet the already expressed Railways need to be able to fit an X=1 infrastructure with PS, the Agency has investigated how the PS functionality can be achieved by default without the need for any explicit trackside orders, identifying the pros and cons (see attachment "ERA action no trk orderv4.docx").

EUG 03-03-2015See attachment "Review ERA action no trk order v4" for the comments of the EoG WG on the ERA proposal.

EECT 10/03/15The review of the comments from EoG WG on the paper “ERA action no trk order v4” (03/03/15) is stopped at comment # 6, because UNISIG tables the idea to upload and store on-board the transmission mode (CS or PS) together with the authentication keys. As a result, the need to send from trackside this transmission mode (entry into an RBC area) or to memorise the transmission mode of the last session (SoM) would disappear completely and would drastically simplify the whole picture for ETCS PS functionality.

The likelihood of having CS still up and running while PS not is then discussed and since it appears that it can only happen when the SGSN (which are usually redounded) is down, it is proposed not to specify any feature with regards to such unlikely situation, especially because it will not exist anymore in the “PS only” target communication system. As a result if the PS service is down, the same operational procedures as today should be applied when the radio communication service is down, e.g. to move the trains in SR mode without any connection to the RBC.Post meeting note: During the discussion, the “short number” feature, which could however be used to trigger a CS radio

connection was overlooked.ERA remarks also that for the off-line key management, it is unclear how the coexistence of B2 and B3 MR1 trains with B3 R2 trains could be managed. Therefore the impact on Ss-038/SUBSET-114 of such proposal to manage the transmission mode together with the authentication keys needs to be assessed by UNISIG.

In the light of the above and of the six first comments of the EoG WG review sheet, the following principles are agreed and confirmed: - The ETCS PS service set-up is made of both the GPRS attach and the PDP context activation with the ETCS APN - As long as there is no need to use the two MTs for CS communications, the attempts to set-up the ETCS PS service are made continuously (polling function) by the ETCS on-board on one (and only one) MT as soon as it is registered to a given radio network. As a result, there is no need to worry about developing such function in the MT (see also minutes of EECT #06).

On the other hand the following principles need to be further checked: - The RBC/RIU transmission mode shall be uploaded and stored on-board together with the authentication keys and shall always be used by the on-board when it is necessary to establish a radio connection - When the ETCS PS service is not set up and the transmission mode is PS, no radio connection shall be established and the driver shall be informed in the same way he is today (exception TBC: in SoM, selection of “short number” by the driver)

UNISIG 08/04/15See attachment “CR741 action 07.09-U.docx” for a first assessment of the impact on SS-038/SS-114 of the proposal to manage the transmission mode together with the authentication keys.

EECT 16/04/15Regarding the transmission mode sent together with the authentication keys, The the following EUG reservations are discussed: 1) Mixing the functionality of two separate systems into a single key authentication message: sending the transmission mode together with the authentication keys is not perceived as really bad engineering since both concerns the radio communication. This is definitely not as bad system design as for instance sending the telephone number, which is a communication feature with signalling information from balises. EUG also identifies the following risk: if the authentication key mechanism disappears before the CS transmission mode, then the need to keep an on-board look up table with RBC IDs would remain for the sake of only the transmission mode. This risk is however considered very unlikely to become a real issue one day.

2) Update of keys + transmission mode when a B2 trackside introduces PS: For a train fleet running on the B2 trackside upgrading to PS, it is clarified that: - In case its home KMC is B2, the key is by definition managed offline. The fact that the transmission mode is appended to

the key does not really add any burden on the current key management procedure. In other words, whether the update is due to a change of the key itself or of the transmission mode does not really make a difference. It could also be envisaged that instead of notifying the home KMC, the change of the transmission mode is directly provided to or requested by the RU in charge of this train fleet. Adding the transmission mode to the actual key can indeed be directly handled via the key downloading tool (which is anyway supplier specific). This would mean no impact at all for the B2 home KMC. - In case its home KMC is B3R2, the concern is irrelevant if the KMC uses the online KMS. If it used the offline one, the same arguments as for a B2 KMC stand.

3) Compatibility with the current BDK solution for online KMS: UNISIG already identified other discrepancies that make the BDK solution not compatible with the KMS WG solution. It is also underlined that if as stated by EUG, BDK really follows the KMS WG development; it includes by definition the discussion about the transmission mode.

From the above discussions, none of the EUG reservations really invalidates the UNISIG proposal. It is also highlighted that the EUG idea of a configuration table for B3.1 on-board listing the B2 trackside transmission mode is very close to the above proposal of appending it via the key downloading tool. Somehow, there is one new configuration parameter to be managed for the B3R2 on-board.

While EUG is requested to reconsider their position in the light of the above discussion, UNISIG is requestedto develop the use cases announced in the attachment “CR741 action 07.09-U.docx” (08/04/15).

EUG 08/05/15See attachments "Comp_solutions_Radio_Bearer_Service.docx" and "ETCS over GPRS Options Matrix v2.xlsx" for a new overview of all the possible options to select the radio bearer service.

EECT 12/05/15The EUG inputs 08/05/15 are introduced.EUG explains that the Excel matrix was created to support the discussion at NPM level. Although these papers could not be exhaustively reviewed prior to the meeting, ERA welcomes them as a good input for a further discussion on the pros and cons of each option. In particular, the EUG paper “Comparison of Solutions for selection of Radio Bearer Service” is at first sight perceived by ERA as a very fair and neutral analysis of all the possible options tabled so far.In particular the option 5 is discussed: actually it consists of an enhanced option 4, with the possibility to update continuously (via DNS queries) the table of RBC transmission modes stored on-board. UNISIG wonders if there could be no table of transmission mode configured at all and that the table could be populated progressively via DNS queries for each of the RBC id for which keys are stored on-board.Regarding when the DNS queries should be triggered, ERA

observes that with class B MTs, it cannot be on reception of a RBC connection order because no such DNS query can be made while the MT is making a CS call set up.Regarding the section 6 (Compatibility with the Danish ETCS over GPRS Solution), ERA stresses that it contains a wrong assumption (“The foreign trains will simply ignore the ETCS packets that they don’t understand coming from the balises in the Danish infrastructure”): on reception of ETCS packets whose number are considered as spare values, the ETCS on-board will trigger a safe reaction (service brake command). ERA recommends therefore that these packets which will be used for Danish national functions are programmed according the ETCS specifications, i.e. they are encapsulated into packets 44.

EUG 27/05/15See attachment "Use Cases - DNS Query v0c.docx" for an improved description of solution 5 in attachment "Comp_solutions_Radio_Bearer_Service.docx" delivered on 08/05/15

ERA 02/06/15We have only a few editorial comments against the EUG entry 27/05/15, see revision marks in the attachment "Use Cases - DNS Query v0c_revERA.docx". In addition, we consider this solution as the only one to be retained and to be incorporated as the master piece of the CS/PS dual stack specification in the SUBSET-037.

UNISIG 05/06/15See attachment "Comp_solutions_Radio_Bearer_Service-U.docx" for UNISIG comments on document "Comp_solutions_Radio_Bearer_Service.docx" posted by EUG on 08/05/15.

EECT 09/06/15The UNISIG comments (05/06/15) against the EUG document 08/05/15 “Comp_solutions_Radio_Bearer_Service.docx” are reviewed, see EECT tags inserted in the Word comments and the resulting revision marks in the attachment "Comp_solutions_Bearer_Service-EECT090615.docx".In particular an important clarification takes place for the UNISIG Euroradio WG representatives: while they consider that only a binary choice CS/PS for the transmission mode is not enough to ensure that any not yet existing radio technology that could be used in the future is taken into account, ERA and EUG recalls that this binary choice already covers all the known IP based technologies (i.e. 3GPP including UMTS and LTE and non 3GPP such as WiFi) that could be used in a foreseeable future. Moreover the selection of a specific radio technology, even when multiple technologies could be available, should not be handled by ETCS.UNISIG also argues that the DNS query approach is too restrictive and does not allow any other communication related information such as the radio network ID to be managed directly by the communication layers as it would be possible with the onboard table solution. ERA answers that this is out of scope of the discussion since nobody requested so far to make such possible enhancement on how the radio network ID is managed

More generally ERA stresses that, unlike what is believed by UNISIG, there is and there will never be any need to specify ETCS variables (wherever they are in the system) which should anticipatively make room for all unknown future radio technologies (as ERA thinks that it has unfortunately been done for the DK packets) or future functions because if a variable has to be extended or new variables are needed, ETCS has a controlled system version management to cope with that.Considering the above, ERA decides to reject the UNISIG comment #4.

Both EUG and UNISIG are requested to state their most preferred solution and their less preferred solution (with a rationale), amongst the 5 solutions exhaustively analysed in the attachment "Comp_solutions_Bearer_Service-EECT090615.docx":

- EUG states that the preferred one is the solution 5 and the less preferred is the solution 3 (rationale: it mixes communication with security and it is not a future proof solution); EUG also adds that solution 5 has been unanimously agreed by EUG members except BDK, however this latter could accept it if it is made fully compatible with the BDK solution. - UNISIG states two equally preferred ones (1 and 3) while the solution 5 is the less preferred one (rationale: the solution is not mature enough and is not future proof) From the exhaustive pros/cons analysis and the positions of EUG and UNISIG, ERA decides to retain the solution 5.

Regarding the EUG statement about the B3R2/BDK compatibility, EUG adds that a B3 R2 train shall run on the Danish network whatever solution is finally retained by BDK. In practice EUG suggests that for a standard B3R2 train to inhibit the safe on-board reaction when reading the DK packet numbers. ERA considers this statement inacceptable. It is a fact that projects in DK implemented unilaterally ETCS packets without consulting ERA, therefore at their own risk. ERA also underlines that there is an already existing feature in the system to handle such national functions, i.e. packet 44. The simple solution should therefore consist in encapsulating the currently engineered DK packets in packet 44.

In addition ERA highlights that a question from a previous EECT meeting has not been fully answered, about the use of the short number by the driver in PS trains when the RBC memorised transmission mode is PS but PS service is temporarily not available. In such a case the selection of “use short number” by the driver could consist of a manual CS fall back.

EUG 24/06/15The 11E017 “ETCS over GPRS principles and functional requirements” has been updated to include all the agreed decisions made in the previous EECT meetings, see attachment "11E017-2B ETCS over GPRS principles.docx". Decisions made in the EECT and included in the updated 11E017-2B are:- EGPRS will be mandatory (covered under 3.1.1.1).

- Two ETCS communication sessions should be managed at all times (assumption there are always 2 MTs for the ETCS application) (covered under 3.2.1.1)- PDP context activation will automatically follow GPRS attach if possible. (Covered under 5.1.1.3)- As long as there is no need to use the two MTs for CS communications, the attempts to set-up the ETCS PS service are made continuously (polling function) by the ETCS on-board on one (and only one) MT as soon as it is registered to a given radio network. (covered under 5.1.1.4 & 5.2.1.8.2)- The likelihood of having CS still up and running while PS not is low since it appears that it can only happen when the SGSN is down, it is proposed not to specify any feature with regards to such unlikely situation, especially because it will not exist anymore in the “PS only” target communication system. (covered under 6.1.1.2).- MTs could be used for other applications such as the KMS APN, as long as ETCS can always establish 2 comms sessions. (covered under 3.2.1.2)- Use of Solution 5 – DNS query response (covered under 5.2).

ERA 03/07/15See attachment "ETCS over GPRS principles_v2B_ERAreview.docx" for the ERA comments on document "11E017-2B ETCS over GPRS principles.docx" posted by EUG on 24/06/15.

UNISIG 07/07/15See attachment "ETCS over GPRS principles_v2B_Ureview.docx" for the UNISIG comments on document "11E017-2B ETCS over GPRS principles.docx" posted by EUG on 24/06/15.

EECT 09/07/15The various actions identified in EECT 09/06/15 (see attachment “Comp_solutions_Bearer_Service-EECT090615.docx”) are reviewed:

1) To check with UIC whether harmonised IP addressing and network interconnection is envisaged:The ERA input in attachment “EECT_ActionPoint10-01_CR741.docx” is discussed.EUG wonders how the On-board equipment will contact the DNS in the local network. ERA explains that two options are possible: either the local DNS IP address can be returned to the on-board after performing the PDP context activation or the on-board could use a default IP address to contact the DNS. It is nevertheless observed that if the default DNS IP address (to be compared with default routers address e.g. 192.168.x.1) option is retained this should be harmonised for all railway networks.The problem of an on-board reaching its home KMC from abroad is then discussed. UNISIG compares the situation where in CS there is an international numbering scheme in EIRENE, while unlike the public worldwide IP addressing plan there is no international IP addressing plan for railways. According to UNISIG, IP private networks can not be reached from outside if there is no harmonised IP addressing plan. ERA remarks that for obvious security reasons, it is very likely that the national railway networks will disclose only

one single public IP address to enter into their network.ERA explains that the following should rather be ensured: an harmonised way to compose the KMCs domain name (FQDN) is needed too, together with the necessity for each infra manager to set-up an appropriate IP network configuration (look-up tables and nodes configuration), in order to allow the IP connection between an on-board attached to any GPRS network and its home KMC, with the on-board only sending to the roamed network the KMC FQDN.The EURORADIO WG worries how the on-board composes its home KMC FQDN: ERA recalls that unlike the RBC ETCS id that is sent by trackside or captured by driver, by definition an on-board has only one home KMC, which means that its FQDN shall be configured on-board. ERA also remarks that whatever and in whichever document it is specified (e.g. SUBSET-037 or FFFIS EURORADIO), the needed requirements shall be a part of CR1237. Indeed the enabling of an international IP connection is only triggered by the on-line Key Management function and not by the fact that packet switch is incorporated in the specifications.

2) 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:The option to use a DNS response of type “TXT” (preferred by EUG and UNISIG) is retained. Justification: the use of an error code and only DNS replies of type “A” (as suggested by ERA) would not allow discriminating a PS RBC whose link with the DNS is temporarily broken from a CS RBC and would therefore lead to an unwanted automatic fall back to CS.The content of text response from the DNS is then discussed. Regarding the EUG suggestion that the RBC phone number could be inserted in the text string for some future purpose, it is recalled that there would be no justified use of such information by the on-board since a DNS query can only be attempted by the on-board when the RBC data (including the telephone number) are known and valid. As also underlined in the EECT 09/06/15, ERA recalls that there is and there will be no such “for future purpose” add-ons in the ETCS specifications.It is therefore agreed that the DNS response of type "TXT" shall contain only the text "CS". Of course it is also underlined that in case of PS RBC the answer to the DNS query is of type "A".

3) 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?:The UNISIG Euroradio WG confirms that they do not see any problem to make the selection of the PS or CS stack only on the basis of the on-board table entry stored at the time of the request.

4) should the “use short number” selection by the driver be inhibited in case the connection set up with a PS RBC has failed?:EUG clarifies that the use of the EIRENE short code number shall be available to the driver in order to attempt a CS connection if there

is a failure to connect or a loss of connection in PS. This must be done following operational rules. See also answer to ERA comments #4 and 5 in attachment “ETCS over GPRS principles_v2B_ERAreview_EECT.docx”.

Concerning the review of the “ETCS over GPRS principles” document in version 2B, the ERA comments 03/07/15 are discussed, see attachment "ETCS over GPRS principles_v2B_ERAreview_EECT.docx" for the answers.

EECT 22/07/15The review of the UNISIG comments on the “ETCS over GPRS principles” document in version 2B is completed (see tags EECT 090715 and EECT 220715 inserted inside Word comments in the attachment “ETCS over GPRS principles_U_EECT220715.docx”).

EUG 04/08/15See in attachment "11E017-2C ETCS over GPRS principles.docx" the version 2C of the “ETCS over GPRS principles” document with all the accepted comments from the version 2B review, together with the resulting modifications to the FFFIS Euroradio (see attachment "A11T6001_v12.64r2.pdf").

UNISIG Euroradio WG 07/08/15See in attachment "Subset-037 v311G.docx" the version 3.1.1 G of Subset-037, in line with 11E017-2C ETCS over GPRS principles and with Radio Transmission FFFIS for EuroRadio v12.64r2.

EECT 09/09/15The various actions identified in EECT 09&22/07/15 are reviewed:

1) To check that there is a harmonized way to reach the DNS in all networks at least in EU:See attachment "ActionPoint11-03_U_EECT090915.docx".

2) To clarify the IP architecture and to derive the necessary provisions/ interoperability requirements to enable the IP connection between an on-board located abroad and its home KMC:See attachment "ActionPoint11-04_U_EECT090915.docx".

3) To analyse if we need to differentiate for the driver the PS service failure from a radio connection failure:The EUG input reads as a follows: “After some discussion CER agreed that they are prepared to accept the use of the existing lost connection icon to control the situation when packet switching fails and circuit switching is still available as the failure of packet switching will be rare in a well-designed network.”Conclusion: it is agreed that the existing lost connection icon is used also in case of connection failure due to the PS service not set-up.

4) To provide a proposal for the PS disconnection handling (either option 1 or 2):Considering the UNISIG statement (see attachment "CR741 action 12 02.msg"), it is agreed not to harmonise the behaviour of the RBC about how to manage double connections.

5) To update the “ETCS over GPRS principles” with all the agreed comments:In the version 2C delivered on 04/08/15, UNISIG stresses that a decision about clause 5.2.1.13 has not been implemented by EUG while it should have been, probably because it was (wrongly) quoted as rejected.

6) To deliver the SUBSET-037:The outstanding ERA/EUG/UNISIG SG comments on SUBSET-037 Euroradio FIS v3.1.1.G are discussed, see tags “EECT090915” in the attachments "SUBSET-037v311G_ERAreview-EECT090915.docx", "Review Subset-037 v311G_EoG_EECT090915.docx" and "Unisig_COM_ S37v311G-EECT090915.doc".

7) To deliver the Euroradio FFFIS:The UNISIG comments on the A11T6001 Euroradio FFFIS v12.64 r2 are reviewed, see tags “EECT090915” in the attachment "Unisig_COM_A11T6001v12.64r2_EECT090915.doc".

EUG 28-09-2015See attachment "Radio Transmission FFFIS v12.64r5" for the update of the FFFIS taking into account the agreed comments from the EECT meeting on 09-09-2015. Note that comment number 1 was not (yet) taken into account as explained in the comment sheet also included in the attachment.

UNISIG 29/09/15See attachment "Subset-037 v312.docx" for the update of the FIS taking into account the agreed comments from the EECT meeting on 09-09-2015. In the embedded comments there are the open points still to be closed.See also updated review sheets in attachments "Review Subset-037 v311G_EoG - 29_09_2015.docx", "SUBSET-037v311G_ERAreview-EECT-290915.docx" and "Unisig_COM_CR741-EuroradioFIS v311G-290915.doc".

EECT 06/10/15Regarding the SUBSET-037: some comments/replies of the version 3.1.1 review sheets are revisited or refined; see tags “EECT061015” in the attachments "Review Subset-037 v311G_EoG_EECT061015.docx" and "Unisig_COM_CR741-EuroradioFISv311G-EECT061015.doc".

Regarding the FFFIS Euroradio: some comments/replies of the version 12.64 r2 review sheets are revisited or refined; see tags “EECT061015” in the attachment "Unisig_COM_CR741-FFFISv1264r2_EECT061015.doc".

UNISIG 28/10/15See attachment "Subset-037 v314.zip" for version 3.1.4 of Subset-037.This attachment contains:- Version 3.1.4 without revision marks- Version 3.1.4 with revision marks vs version 3.1.2- Version 3.1.4 with revision marks vs version 3.1.0

The following points are still open:- Reference to QoS parameters for KMS (a reference point like the FFFIS ER to define these values is missing)- Multiplexing protocol 27.010

ERA GSM-R CCM 03/11/15Attachment "gsmr9225-1 2.docx" contains the changes proposed in the EIRENE SRS related to the PS introduction. It also includes the modifications required for the CR 1237 "KMS evolution". Discussion on the sections highlighted in yellow is not closed yet.

EUG 03/11/15See attachment "Radio Transmission FFFISv12.64r7_1.pdf" for the updated FFFIS Euroradio version 12.64r7, with all agreed comments implemented.

EECT 04/11/15EIRENE SRS:The modifications to the EIRENE SRS are presented by UIC. The following items are discussed and clarified: - The domain “.etcs” shall only be used for ETCS entities. It is agreed to make a request for a public domain. - The support of multiple PDP contexts and of multiplexed interface by the EDOR is considered as a M requirement, not MI, as it would be an implementation issue. - The time that the data communication is disrupted due to radio cell change is currently considered as M only in the document. The specific values proposed are still under discussion. ERA/EUG remark that high values may impact the performance and that the concerned requirement could rather be classified as MI. UNISIG explains that, for the PS data, the upper protocol layers take anyway care of error correction/repetitions; and that disruption of around 1 second would be acceptable. The values suggested are within that range, therefore it is agreed to keep this requirement classified as M - A revision of the references included in the EIRENE document is suggested: in particular the documents from Annex A should not include version references, as these are the ones indicated in the TSI. - QoS defined for ETCS application is MI. For details, see tags “EECT041115” in the Word comments inside the attachment "gsmr9225-1 2-EECT041115.docx".

Regarding QoS, the profile is defined at the GSM-R network; the only thing that has to be requested is that it is “Streaming” for ETCS. The other parameters are predefined. The SUBSET-037 must reflect that.

SUBSET-037:Three batches of comments (against version 3.1.3 and 3.1.4) from individual railways have reached directly the ER WG, with no circulation prior to the meeting. The two batches against version 3.1.3 were pre-discussed within the ER WG while the one against version 3.1.4 has only been processed by the ER WG leader (Frank Kaiser). Some of the comments are discussed during the meeting, see tags EECT151104 inside the attachments "Review Subset-037

v313 DB + ERWG.docx", "Review subset-037 v313 ProRail + ERWG.docx" and "Review Subset-037 v314 ProRail + Frank.docx".

Regarding the discussion on TCP parameters: EUG requests to make as much as possible configurable all these parameters from trackside point of view, they consider that recommending values in the SUBSET-037 could be an interoperability problem if the solution does not work with such a recommendation. UNISIG clarifies that the values recommended are just for information and that what is mandatory is to be inside of the range of values defined in 8.3.3 Table 41. The ER WG intends to provide a document next year to justify their choice; currently they do not have human resources to draft it. EUG points out that the justifications should precede the decision and not the opposite. However ERA stresses that in the frame of the very tight B3R2 programme, the only pragmatic way forward is to trust that the values chosen by the ER WG will be future proof at least until the next release.

ETSI standard 27.010:UNISIG has prepared the necessary modifications to the SUBSET-037 chapter 6, in order to make mandatory the implementation of the ETSI 27.010 in the ETCS on-board. Concerning the DLC establishment services, it is agreed not to predefine priority levels for applications other than ETCS (which is given the highest one) because these shall be anyway managed by the EVC, the MT being the slave. See tag EECT151104 inside the attachment "CR_27.010_EECT041115.docx", listing the modifications to the SUBSET-037 chapter 6.

UNISIG 16/11/15See attachment "Subset-037 v315.zip" for Subset-037 updated according to conclusions of 04/11/15 EECT meeting. This attachment contains:- Subset-037 v3.1.5 without revision marks- Subset-037 v3.1.5 with revision marks versus v3.1.4- Subset-037 v3.1.5 with revision marks versus v3.1.0- Consolidated review sheets

ERA GSM-R CCM WG 03/12/15EIRENE SRS: The changes agreed during the last EECT meeting (both for CR 741 and CR 1237) have been included in the attached document “gsmr9225 1-11” in the field "Agreed Solution". Additional agreed modifications, which were discussed between ERA, GSM-R industry, UIC, CER, EIM and Euroradio representatives: - Rewording of requirement for Barring of Calls for ETCS subscribers (section 2.4) - Revision of the expression of the need of handling multiple PDP contexts by the EDOR - Revision of the EDOR requirements for EDOR on cell change and discontinuation of data flow, according to test results available - Wording and formatting improvements - Update of versions of documents in the list of references - Editorial corrections

FFFIS for Euroradio: The attachment “FFFIS for EURORADIO 1264r10-12 4.pdf” contains the changes tracked against the version 12.4, currently in the TSI. It includes the modifications in the different sections related to the CR 741, CR 1262 and CR 1237. It also includes changes (editorial and formatting) related to the introduction of PS, to differentiate the parts that refer to CS from the ones that refer only to PS. The section 4.6.4.17 has been aligned to reflect that the number of ports dedicated to be used for PS-mode based communication should be “at least 2”.

SUBSET-037: As a result of the alignment between documents (EIRENE SRS, FFFIS EuroRadio and SS037), the clause 6.1.1.3 has to indicate that the number of PS services between CFM and mobile terminal should be “at least 2” instead of “up to 4”.

ERA 03/12/15The FFFIS EURORADIO clause 2.1.3.23 must also be modified to replace "at least four PDP context" with "at least two PDP context". See resulting attachment “FFFIS for EURORADIO 1264r10112 4.pdf" in the field "Agreed Solution".

EECT 08/12/15See attachment "B3R2_Udocs-consolidated review sheet_final.docx" for the agreed editorial modifications to the SUBSET-037 v3.1.5. See also resulting SUBSET-037 v3.1.6 in the field "Agreed Solution".

Supporting document(s) for Justification/Discussion for Solution

11E017-2 ETCS over GPRS principles (clean).zip11E017-2A ETCS over GPRS principles.docxBDK versus EoG GAP Analysis v3.xlsxETCSoverGPRS_ERAreview_211014.docxUnisig_11E017-2A_COM_SG_141021.docEoG_ERAreview_211014_EoG-WG.docx11E017-2A comments EUG reply 141125.docBDK versus EoG GAP Analysis v4 141125.xlsxLille_v12_final.pptxLille_CS_connection_ENIF_testtrack.pptx11E017-2A comments_EECT_141201.docEDOR for other applications v4.docxCR741 documents 20150130.zipERA action no trk orderv4.docxReview ERA action no trk order v4.docxCR741 action 07.09-U.docxETCS over GPRS Options Matrix v2.xlsxComp_solutions_Radio_Bearer_Service.docxUse Cases - DNS Query v0c.docxUse Cases - DNS Query v0c_revERA.docxComp_solutions_Radio_Bearer_Service-U.docxComp_solutions_Bearer_Service-EECT090615.docx11E017-2B ETCS over GPRS principles.docxETCS over GPRS principles_v2B_ERAreview.docxETCS over GPRS principles_v2B_Ureview.docx.docxEECT_ActionPoint10-01_CR741.docxETCS over GPRS principles_v2B_ERAreview_EECT.docx

ETCS over GPRS principles_U_EECT220715.docx11E017-2C ETCS over GPRS principles.docxA11T6001_v12.64r2.pdfSubset-037 v311G.docxActionPoint11-03_U_EECT090915.docxActionPoint11-04_U_EECT090915.docxCR741 action 12 02.msgSUBSET-037v311G_ERAreview-EECT090915.docxReview Subset-037 v311G_EoG_EECT090915.docxUnisig_COM_ S37v311G-EECT090915.docUnisig_COM_A11T6001v12.64r2_EECT090915.docRadio Transmission FFFIS v12.64r5.zipSubset-037 v312.docxReview Subset-037 v311G_EoG - 29_09_2015.docxSUBSET-037v311G_ERAreview-EECT-290915.docxUnisig_COM_CR741-EuroradioFIS v311G-290915.docReview Subset-037 v311G_EoG_EECT061015.docxUnisig_COM_CR741-EuroradioFISv311G-EECT061015.docUnisig_COM_CR741-FFFISv1264r2_EECT061015.docSubset-037 v314.zipgsmr9225-1 2.docxRadio Transmission FFFISv12.64r7_1.pdfgsmr9225-1 2-EECT041115.docxReview Subset-037 v313 DB + ERWG.docxReview subset-037 v313 ProRail + ERWG.docxReview Subset-037 v314 ProRail + Frank.docxCR_27.010_EECT041115.docxSubset-037 v315.zipFFFIS for EURORADIO 1264r10-12.4.pdfB3R2_Udocs-consolidated review sheet_final.docx

Preliminary Assessment of Benefits

Capacity: freeing up of GSM R capacity for other services, cell planning would be easier and would allow more flexibility in design to achieve the required capacity (particularly in highly trafficked areas).Spectrum: more efficient use of available spectrum.Quality of service: improvements in session establishment, fewer dropouts, etc.RBC-RBC handovers: potential for smoother RBC-RBC handovers procedures using GPRS multi-session.Inter-working strategy: potential co-existence with circuit switched data ETCS as the basis for interoperability would enable a staged rollout of GPRS ETCS without adversely affecting interoperability.Ability to support other services and other users: as a result of reduced demand for GSM-R radio capacity from ETCS.Reduced equipment in the GSM-R Network: the capacity improvement brought about by the implementation of GPRS may mean that fewer items of equipment such as base station transceivers may be needed leading to lower costs for the network.Future proofing: IP is assessed to have a long term future (at least 25 years) so a move to IP for ERTMS would appear to be a reasonably future-proof decision. Migration of ETCS to other and future communication bearers would be enabledOn-line key management and transfer of diagnostic data: this may be provided simultaneously to ETCS Level 2/3 operation without blocking cell slots for a CSD call. This data transfer could be independent of the safety layer and the RBC using a second

IP/GPRS session.

Supporting document(s) for preliminary Assessment Benefits

GPRS white paper v1.0.zipCER-GSMR-CR001 Annex 2.zip

Economic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

EIM (European Infrastructure Managers)

Contact person name R. BloomfieldContact Person e-mail adress richard.bloomfield@networkrail.co.ukEndorsed by Recognised Organisation(s)Project Information Future Projects; 2010Submitter Reference Number EIM/ERTMS/CR/001List of assigned WG(s)Severity Performances impact, non interoperability and non safety relatedTarget Baseline Release ETCS B3R2 & GSM-R B1Reason for Error/Enhancement reclassificationReason for rejectionReason for postponement Control Group decision 08/03/07Superseding CRList of superseded CRs Date of Submission 2006-08-24 02:00:00 AMLast modification date 2016-01-06 04:12:49 PM

Identification number 0852State Presented_to_ECHeadline Definition of level 2/3 area and level transition borderImpacted System ETCSReference Baseline Release Baseline 3 (1st consolidation release 02/2010)Documents and/or References Subset-026 v3.1.0, 3.5.5.1.Error/Enhancement ErrorProblem/Need description 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

Solution Proposal by submitterSupporting document(s) for solution proposalAgreed Solution Modify SUBSET-023 v3.1.0 and SUBSET-026 v3.4.0 as described

in the attachment "Solution_for_CR852_101215.docx"Supporting document(s) for agreed solution

Solution_for_CR852_101215.docx

Justification/Discussion for Solution

UNISIG 27/05/15See attachment "Solution proposal for CR852_20150527.docx" for a solution proposal.

EUG 02/06/2015UNISIG solution proposal "Solution proposal for CR852_20150527.docx" is agreed by the EUG.

ERA 04/06/15The UNISIG solution proposal has the following two deficiencies:

Modification to the fourth bullet of 3.5.3.7 a): this is a functional change not justified by the CR problem description and above all it consists of a regression with regards to the content of CR764 (see EUG argumentation in item 1 of EUG quote 28/08/08). The aim of this fourth bullet (indeed poorly formulated) was to stop the connection attempts when leaving a level 2/3 equipped area to an area where the level 2/3 is not operated, even if no level transition takes place.

Modification to clause 3.5.5.1: the new item g) indeed fills a small gap and describes a case not specified so far, however the new item h) is already specified in 5.15.4.3&4. Actually it appears that the list of items in clause 3.5.5.1 has evolved in very cahotic way and that the UNISIG solution proposal just worsens this: some items (c and f second part) are also explicitly specified elsewhere in the SRS, some are not specified anywhere else (d, e and f first part) and one item (b), even if could intend to refer to all the other cases, is written in a very confusing way as already spotted by CR1256.

It is therefore proposed to restore the functional meaning of 3.5.3.7 a) fourth bullet by relying on the new SUBSET-023 definitions proposed by UNISIG and to clean up the clause 3.5.5.1 item list, by re-apportinoning whenever necessary the trigger events and by clarifying (as suggested by CR1256) the item b). See attachment "Solution proposal for CR852_revERA_040615.docx" for details.

EECT 10/06/15UNISIG proposes the following editorial modifications to this ERA counter proposal 04/06/15: - To align the wording of clause 3.5.3.7 a) 4th bullet with the Ss-023 proposed definitions to read "The train passes with its front end a level transition border from a level 2/3 area to an area where level 2/3 operation is not supported", - To delete the examples in 3.5.5.1 b) that could lead to misinterpretations for the readers

With the above modifications (see parts highlighted in blue in the attachment "Solution proposal for CR852_EECT100615.docx"), the

solution proposal is agreed.

EECT 08/12/15The following amendments to the solution 10/06/15 are agreed:

- Add new entry “level 2/3 area” to SUBSET-023 to read “Trackside area in which level 2 and/or level 3 operation is supported.”- The deletion of 3.5.5.1 e)” should be also followed by a new clause in section 3.15.1.3 for the case of a RBC-RBC handover.- There are other clauses which make also reference to the clause 3.5.5.1.e): In clause 3.5.7.6 b), replace “3.5.5.1 e) and 3.15.1.2.7” with “3.15.1.2.7 and 3.15.1.3.9”, in clause 3.16.3.5.4, delete “(moved to 3.5.5.1e)” and in clause 3.15.1.3.2 b) (moved by CR1184), delete “refer to 3.5.5.1e and 3.15.1.2.7”.- the clause 5.10.1.1 seems to be ambiguously worded, in a similar way to the clauses that are modified in Chapter 3 - Unlike the action “having passed with its min safe rear end the level transition border” referred to in the similar clause 5.10.3.10.6, the action “having changed from level 2/3 to any other” is not performed by the train. The new clauses 5.10.3.3.5, 5.10.3.6.5, 5.10.3.10.6 should also be rephrased to avoid this abuse of language

For details, see parts highlighted in blue in the attachment "Solution_for_CR852_101215.docx" in the field "Agreed Solution"

Supporting document(s) for Justification/Discussion for Solution

Solution proposal for CR852_20150527.docxSolution proposal for CR852_revERA_040615.docxSolution proposal for CR852_EECT100615.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name L. RepettiContact Person e-mail adress luca.repetti@ansaldo-sts.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number 852List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponement The purpose of the CR is not clear. Is this really needed for

interoperability?At most 3.5.3.7 a) and 3.6.5.1.4 could be slightly improved to read: "(on executing a transition from level 2/3 to 0,1;STM)"

Superseding CRList of superseded CRs 1256

Date of Submission 2010-09-12 08:11:27 PMLast modification date 2016-01-06 04:10:51 PM

Identification number 0933State Presented_to_ECHeadline Storing of RBC contact informationImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-026 v3.3.0 §3.5.3; 4.10Error/Enhancement ErrorProblem/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.

Supporting document(s) for problem/need descriptionSolution Proposal by submitterSupporting document(s) for solution proposalAgreed Solution Modify SUBSET-026 v3.4.0 as described in the attachment "SG

solution for CR933_101215.docx"Supporting document(s) for agreed solution

SG solution for CR933_101215.docx

Justification/Discussion for Solution

UNISIG 24/10/14We propose to add new clauses 5.15.1.4.1 and 5.15.1.4.2 in Subset-026 to read:"5.15.1.4.1 When the handover is executed, the on-board shall substitute the current RBC ID/Phone number with those of the Accepting RBC. 5.15.1.4.2 Note: the on-board also retains the RBC ID/Phone number of the Handing Over RBC until the communication session with the Handing Over RBC is terminated."

This solution proposal only addresses the first part of the problem description ("There is no requirement in the SRS about when the RBC contact data ...").The second part of the problem description ("Further, the RBC contact data are deleted according to 4.10...") is no more supported by the Super Group, i.e. the Super Group does not request anymore the deletion of the RBC contact data when level 1 is entered.

EECT 04/11/14According to ERA, the term “the handover is executed” does not correspond to a specific event in the RBC/RBC handover. Actually, it stands for all actions to be performed after a packet 131 has been received. The specific event leading to the change of RBC ID/phone number stored on-board shall be when the supervising RBC changes from the HO to the ACC one i.e. when the on-board sends a position report directly to the Accepting RBC with its maximum safe front end having passed the border (see SRS 3.15.1.3.5). In addition, in SH/PS mode, no RBC/RBC handover is really executed but the new RBC ID/phone number are still to be stored (see

4.4.8.1.5.2, 4.4.20.1.13).UNISIG explains that the execution of a level transition corresponds to the event of passing the level transition border and therefore by comparison what they want to express with “the handover is executed” is the train front end (estimated) passing physically the RBC/RBC border. In addition the clause 5.15.1.4 was seen as a hook, where the term “execute the handover” can be found in the same context of passing the RBC/RBC border.However, according to ERA the proposed note is not complete: at least “and the min safe rear end has passed the RBC/RBC border” should be added. ERA also wonders if this is really a note: in the case the train front is in advance of the RBC/RBC border but the tail of the train is still in rear, it must be clearly specified (with a requirement and not with a note) that the OBU should then call back the HO RBC when the connection with this latter has been lost (this is especially relevant for level 3).ERA also suggests that the right location for any additional requirement should be in chapter 3 (e.g. 3.15.1.3.7), also underlining that the clause 5.15.1.4 is almost a non requirement.Conclusion: UNISIG to rework the solution proposal according to the above and to make sure that the right RBC is called in all possible cases (e.g. where the train front/rear are located and the number of sessions that can be handled at the same time).

UNISIG 21/11/14See attachment "SG solution proposal for CR933_20141118.docx" for a reworked solution proposal as per conclusion of 04/11/14 EECT meeting.

EUG 28-11-2014Agreed

EECT 03/12/14According to ERA, the UNISIG solution proposal (21/11/14) goes in the right direction for what concerns the specific case of RBC/RBC HO only, however it relies on a notion (“current RBC ID/phone number”) that does not exist in the SRS and the patches to tables A.3.4 and 4.10 are questionable too.It is advised that at least the relationship between the sentences 3.15.1.3.7 & 8 and the tables A.3.4 and 4.10 should be improved (e.g. replacing “current” with “currently stored” in 3.15.1.3.7).Regarding the concept “RBC ID/Phone Number of the Handing Over RBC”, ERA wonders if no confusion can happen with the current RBC ID phone number when the the RBC transition order is deleted before the border is crossed (e.g. route cancellation): UNISIG clarifies that this is an additional storage, which at the latest should be effected when the the border is crossed, however this is implicitly reflected in the UNISIG proposal.In addition, what is behind the line "RBC ID/ phone number” in these tables is more than ever underspecified and should be clarified too. A tentative clarification could be: the stored RBC ID/ phone number is the one that is received first from a trackside order or from driver data entry at SoM and it is only substituted during a RBC/RBC HO, as proposed by UNISIG. UNISIG claims that this clarification goes beyond the scope of the problem description of the CR, however ERA insists that according to the title, to fill this gap is fully

legitimate.Moreover, the second part of the problem description (although withdrawn by UNISIG) remains: When exiting from level 2/3 to level 0/NTC and the train rear end is still in the RBC area, it is obvious that the RBC ID/phone number cannot be deleted on entering SN/UN.

ERA 04/02/15See text highlighted in blue in attachment "SG solution proposal for CR933_ERA040215.docx" for an updated solution proposal as per conclusions of EECT meeting 03/12/14

UNISIG 07/02/15ERA solution proposal posted on 04/02/15 specifies that, after the substitution, the on-board retains the RBC ID/Phone Number of the Handing Over RBC until the RBC transition order is deleted. It is not clear to the SG when the RBC transition order is deleted in case the deletion is not related to SRS A.3.4 or 4.10. The SG therefore proposes to modify ERA solution proposal to make more deterministic the moment the RBC ID/Phone Number of the Handing Over RBC is deleted (see revision marks in attachment "SG solution proposal for CR933_ERA040215_SG.docx"). The modifications proposed by SG also include the replacement of "previously" with "currently" in exception [14] of table in 4.8.3.

UNISIG 27/02/15This posting supersedes the posting dated 07/02/15.UNISIG solution proposal posted on 21/11/14 and ERA solution proposal posted on 04/02/15 specify that, after the substitution, the on-board retains the RBC ID/Phone Number of the Handing Over RBC until the RBC transition order is deleted. It is not clear to the SG when the RBC transition order is deleted in case the deletion is not related to SRS A.3.4 or 4.10. The SG therefore proposes to modify ERA solution proposal to make more deterministic the moment the RBC ID/Phone Number of the Handing Over RBC is deleted (see revision marks in attachment "SG solution proposal for CR933_20150227.docx"). The modifications proposed by SG also include the replacement of "previously" with "currently" in exception [14] of table in 4.8.3, as well as a precision in clause 3.18.4.3.1 that only the announced RBC transition orders are excluded. The modifications compared to ERA solution proposal posted on 04/02/15 are highlighted in yellow in attachment "SG solution proposal for CR933_20150227.docx".In addition to these modifications highlighted in yellow, the following changes have been made:- proposed note 1 about the possible causes for the deletion of the RBC transition order is removed- 3.18.4.3.1 is renumbered before being modified (and not the opposite as in ERA proposal)- modification to table A3.4 is removed- modification to line "RBC Transition Order" of table in 4.10 is removed.

EUG 03-03-2015We have 2 remarks on the UNISIG proposal of 27/02.1) We suggest to enhance the text in brackets in 3.18.4.3.1 to read

"(excluding announced RBC transition orders, see exception [14] in table 4.8.3 for details)".2) We do not understand why in 4.8.3 the exception [14] is only included in the row "no" and not in row "yes". Could you clarify?

ERA 03/03/15We agree on the UNISIG improvements posted in attachment "SG solution proposal for CR933_20150227.docx" with 2 exceptions:- 1st bullet of 3.15.1.3.8: we think that the RBC id/phone number shall not be deleted till the session is terminated which as a matter of fact occurs well after the min safe rear end has passed the RBC/RBC border, see 3.15.1.2.7 and 3.5.5- modification to clause 3.18.4.3.1: we think that it is a regression with regards to the proposal in attachment "SG solution proposal for CR933_ERA040215.docx". The text was meant to refer exclusively to packet 42. The event "reception of an order to execute the RBC transition immediately" was already covered by the expression "from the crossing of a RBC/RBC border (see clause 3.15.1.3.7)". This supersedes the EUG comment #1 dated 03/03/15.

Regarding the EUG comment #2 dated 03/03/15: It is on purpose that exception [14] was not added to the row "yes" because we did not see what could trigger the sending of a packet 42 while an RBC/RBC handover is on-going.

EECT 09/03/15The ERA and EUG comments 03/03/15 are reviewed and the solution proposal updated by UNISIG (27/02/15) is agreed with two modifications to clauses 3.15.1.3.8 first bullet and 3.18.4.3.1, and also with few other editorial findings (see text highlighted in blue in the attachment "SG solution proposal for CR933_EECT090315.docx").

EECT 08/12/15In the attachment "SG solution proposal for CR933_EECT090315.docx", the exception [14] from table 4.8.3.1.1 is not reflected in the figure 3.See part highlighted in blue in the attachment "SG solution for CR933_101215.docx" in the field "Agreed solution".

Supporting document(s) for Justification/Discussion for Solution

SG solution proposal for CR933_20141118.docxSG solution proposal for CR933_ERA040215.docxSG solution proposal for CR933_ERA040215_SG.docxSG solution proposal for CR933_20150227.docxSG solution proposal for CR933_EECT090315.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name L. RepettiContact Person e-mail adress luca.repetti@ansaldo-sts.com

Endorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number 933List of assigned WG(s)Severity Interoperability and non safety relatedTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs 1261

Date of Submission 2013-12-20 05:13:58 PMLast modification date 2016-01-06 04:10:51 PM

Identification number 1014State Presented_to_ECHeadline Duplicated balises ambiguitiesImpacted System ETCSReference Baseline Release Baseline 3 (1st consolidation release 02/2010)Documents and/or References Subset-026 v3.1.0Error/Enhancement ErrorProblem/Need description 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.

Supporting document(s) for problem/need descriptionSolution Proposal by submitterSupporting document(s) for solution proposalAgreed Solution Modify SUBSET-026 v3.4.0 as described in the attachment

"Solution_for_CR1014_101215.docx"Supporting document(s) for agreed solution

Solution_for_CR1014_101215.docx

Justification/Discussion for Solution

UNISIG 24/10/14See attachment "SG solution proposal for CR1014 - 20141023.docx" for a solution proposal.

EECT 04/11/14EUG consolidated position neither received prior to the meeting nor expressed during the meeting.First part of the proposal (modification to clause 3.16.2.4.7) agreed by ERA only.

Second part of the proposal (modification to clause 3.16.4.2 and to M_ERROR description):UNISIG introduces the new notion that a duplicated balise not correctly read does not consist of BG message consistency error and explains that it could be interpreted that a missing duplicated balise does not lead to the sending of the M_ERROR. According to ERA, there is no room for such interpretation because it is stated “regardless if there is an error reaction” in clause 3.16.4.2 and the description of the variable clearly refers to 3.16.2.4.1 which itself includes the list of items a) to d). In other terms, according to 3.16.2.4.1 and 3.16.4.2 when a duplicated balise is missed it shall always be reported to the RBC.

Third part (modification to chapter 8): agreed by ERA only but with the following numbering 8.4.1.4.10.

See updated solution proposal in attachment "SG solution proposal for CR1014_EECT041114.docx"

EUG 25-11-2014The proposal from the EECT 04/11 is agreed.

EECT 08/12/15The numbering of the new clause 8.4.1.4.10 prevents the addition of any other exception without lowering again the numbering level.See part highlighted in blue in the attachment "Solution_for_CR1014_101215.docx" in the field "Agreed solution"

Supporting document(s) for Justification/Discussion for Solution

SG solution proposal for CR1014 - 20141023.docxSG solution proposal for CR1014_EECT041114.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name L. RepettiContact Person e-mail adress luca.repetti@ansaldo-sts.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number 1014List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2

Reason for Error/Enhancement reclassificationReason for rejectionReason for postponement No solution proposal provided in due time by the submitter.

Even though the wording of 3.16.2.4.8.2 could be improved, the M_MCOUNT check will always win. Should not be the case according to some implementations, the impact on interoperability is really minor and this non compliance with 3.16.2.4.7 would not harm safety

Superseding CRList of superseded CRs Date of Submission 2010-09-12 08:30:56 PMLast modification date 2016-01-06 04:10:52 PM

Identification number 1033State Presented_to_ECHeadline Disable Start in SR if no safe connectionImpacted System ETCSReference Baseline Release Baseline 3 (2nd consolidation release 12/2010)Documents and/or References SUBSET-026 V320

ERA_ERTMS_015560 V320Error/Enhancement ErrorProblem/Need description 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 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 descriptionSolution Proposal by submitter Modifications to SUBSET-026:

Modify 4.4.11.1.6 to read: "In level 2/3, if the indication status of the safe radio connection is "Connection Up", the driver shall have the possibility to request a new distance to run in Staff Responsible, by selecting "Start". This triggers an MA request.".

Modifications to ERA_ERTMS_015560:Modify table 32, line "Start", the last term (after the last OR) to read: “(mode is SR) AND (ERTMS/ETCS level is 2/3) AND (the connection indication status of the safe radio connection is: Connection Up)".

Supporting document(s) for solution proposalAgreed Solution Modify SUBSET-026 v3.4.0 and ERA_ERTMS_015560 v3.4.0 as

described in the attachment "ERA_solution_for_CR1033.docx"Supporting document(s) for agreed solution

ERA_solution_for_CR1033.docx

Justification/Discussion for Solution

ERA 14/08/14It has to be noted that contrarily to what is proposed by the submitter, the SRS and DMI specifications currently use the status of the communication session to decide whether respectively a radio message has to be sent or a button has to be enabled. The following proposal is therefore based on the status of the communication session.

A similar problem as the one described for SR mode has also been detected for PT mode. According to SRS 5.11.3 S140 and DMI table 33, the driver can press start independently of the status of the communication session.However, it should also be underlined that in SB mode, the “Start” button is always enabled but leads to either an MA request or to an immediate transition to SR depending on whether the session is open or not (see SRS 5.4.5.3 h). This difference in behaviour between SB and PT does not seem to be clearly justified. The present proposal assumes that this difference is intentional.

See attachment "ERA_solution_proposal_for_CR1033.docx" for the details.

UNISIG 29/08/14The ERA solution proposal posted on 14/08/14 is agreed. Note : see attachment "Unisig_SG_COM_CR1033 – 20140829.doc" for a comment not directly related to CR1033 but about a clause impacted by this CR.

EUG 30-08-2014We agree with ERA that the communication session is the right condition to use in this context.One editorial comment on the proposal. In the SRS and DMI spec we can find the following words related to the status of the communication session: "open", "established", "exists". We understand that they all mean the same status. You have used two of them in the proposal. Please select one of the 3 as the preferred wording (open or established) and use that consistently from now on in all proposed modifications for the communication session.Regarding the ERA statement on PT. The ERA solution proposal is consistent with the current difference in the procedures for SB and PT in the SRS. Even though this difference may not seem to be clearly justified, changing it would require a new CR. We therefore support the ERA proposal.

EECT 09/09/14The content of the ERA solution proposal 14/08/14 is agreed by UNISIG/EUG with only the editorial remark from U (regarding the bracket in excess).Regarding the EUG comment: the term “exists” is consistently used everywhere in the enabling conditions tables of the DMI specification while “open” and “established” are broadly used in the SRS.It is agreed to keep the term “open” in the concerned clause 4.4.11.1.6, having in mind that it is not sure that it is possible to replace all the occurrences of “open “and “established” with “exist”.Should the EUG recommendation be taken into account (use only one term throughout the SRS and DMI spec), it could be addressed later in a cover CR for miscellaneous editorial findings.

Supporting document(s) for Justification/Discussion for Solution

ERA_solution_proposal_for_CR1033.docxUnisig_SG_COM_CR1033 – 20140829.doc

Preliminary Assessment of BenefitsSupporting document(s) for

preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

EEIG (ERTMS users group)

Contact person name R. DijkmanContact Person e-mail adress rdijkman@ertms.beEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number EEIG324List of assigned WG(s)Severity Performances impact, non interoperability and non safety relatedTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponement This is a second order ergonomic issue. Also the solution proposal is

not fit for purpose (In the DMI spec the actual radio connection availability is rather used as enabling condition for buttons)

Superseding CRList of superseded CRs Date of Submission 2011-03-25 03:26:35 PMLast modification date 2016-01-06 04:10:52 PM

Identification number 1084State Presented_to_ECHeadline Target speed maskingImpacted System ETCSReference Baseline Release Baseline 3 (2nd consolidation release 12/2010)Documents and/or References Subset-26 v3.2.0Error/Enhancement EnhancementProblem/Need description Problems have been identified on the Cambrian line with the display

of multiple speed targets within a TSM area.The SRS and DMI specification give a clear sequence of events for Target Speed Monitoring (TSM) informing the driver about the approach to a speed target.• Entering Target Speed monitoring (pre-indication). The final target speed and the distance to target are shown from this point for the remainder of the TSM phase. This happens 7s before the indication point would be reached if the train were to be travelling at the maximum permitted speed (and continued to do so). It allows the driver to brake more gradually to the EoA rather than at the last minute (indication point).• Permitted speed on the circular speed gauge reduces. This shows the driver what speed he would receive warnings/interventions at any given time.• Indication point alerts the driver and turns some elements yellow. This is calculated to happen 4s before the driver needs to make a full service brake application to stop at the EoA, but can happen earlier, depending on the proximity of the SvL and the train’s braking performance. In practice the driver will usually already have the brake applied so braking will happen faster.

This sequence is designed to give the driver sufficient time to react adequately to reach the new target speed. However, target speeds are not always sufficiently separated to allow a full sequence to be completed. If the TSM area overlaps for two speed targets, the sequence does not restart. SRS 3.13.10.4.2 specifies that the target shown to the driver (MRDT) should be the one which is currently giving the most restrictive permitted speed. On the approach to two speed targets which are sequentially reducing, the MRDT can change during the TSM phase at an apparently arbitrary time.

Figure 1 (see attachment "EEIG382 figure.doc") shows the calculations resulting from the Baseline 3 brake model for a Class 97 freight train on a real section of the Cambrian line. The target speed shown to the driver is 25kph until approximately 200m from the 15kph speed restriction when the new target is shown. This is an extreme case but the problem occurs to a varying extent and is possible whenever the speed targets are closer than the pre-indication distance.Experience from the Cambrian project shows that drivers may release the brakes on the approach to target 1 having achieved 25kph. In some situations, even if the driver observes and reacts to the change in MRDT immediately there is insufficient time for the brakes to react and an intervention is inevitable.Drivers cannot avoid this situation by knowledge of the speed profile of the route as ETCS effectively enforces speed restrictions before they begin to allow for brake reaction time. This position varies for train configuration.The information on the planning area is insufficient as it does not show the actual target speed. In addition, due to brake reaction time, speed targets are effectively enforced before the location indicated on the planning area.This cannot be avoided by trackside engineering as the separation required between speed restrictions varies for train performance characteristics and is practically unavoidable on existing infrastructure (several km required between speed targets). Furthermore, placement of TSRs will become significantly constrained if target speed masking is to be avoided.The problem is most serious when an EoA target is concealed for most of the approach by a speed restriction.

Supporting document(s) for problem/need description

EEIG382 figure.doc

Solution Proposal by submitter From the beginning of TSM (ie pre-indication point), set the MRDT to the lowest target speed that will be encountered before the end of the TSM area. Note: if there are interim speed restrictions the permitted speed will still require the driver to achieve the target speeds.A second possible approach would be to provide indication of further speed targets that will be encountered in the TSM area to the driver. However, it is not clear how this could be displayed in a way that is clear and useful.

EUG 30/06/14From the two potential solutions listed above, the railways finally retain solution 2, i.e. to give the driver an indication on the DMI of a second target close behind a first (and supervised) target. The

attachment "CR1084 solution proposal_300614.doc" is a first draft of a solution proposal. It is mainly to introduce the principle, the details need to be further discussed and refined, specifically with the operational/DMI experts. The solution 1 is withdrawn.

Supporting document(s) for solution proposal

CR1084 solution proposal_300614.doc

Agreed Solution Modify SUBSET-023 v3.1.0 and SUBSET-026 v3.4.0 as described in the attachment "ERA_solution_for_CR1084_111215.docx".

Supporting document(s) for agreed solution

ERA_solution_for_CR1084_111215.docx

Justification/Discussion for Solution

ERA 23/09/14While the principle proposed by the submitter (see CR1084 solution proposal_300614.doc) to determine if a target is hidden by another one is a sound one, to create a new indication on the DMI to show a second hidden target behind the one currently displayed (MRDT) has the following shortcomings: - if the target to be displayed as a hidden one is the EOA, the release speed will not appear in due time and this does not address one of the problems spotted by the submitter ("The problem is most serious when an EoA target is concealed for most of the approach by a speed restriction") - if there is a third target (presumably the EOA), which is not hidden by the first one (the MRDT) but is hidden by the hidden one displayed with the supplementary hook, the sequence of display to the driver will be unnecessarily confusing (two different pairs of MRDT/hidden target shown in sequence) - if there is a third target (presumably the EOA), which is hidden together with the second one but is not hidden by the second one, this third target will be displayed a hidden target together with the first target and when the second one becomes the MRDT, this latter will appear whille the EOA (together with the release speed) will disappear before re-appearing again later.

We propose therefore to refine the algorithm to select the target to be displayed to the driver, in order to meet the objective of the CR without the need to modify the DMI specifications.This new algorithm ensures that in case of multiple targets close to each other it is avoided that a target is displayed after its Indication supervision limit has been reached.See attachment "ERA_solution_proposal_for_CR1084_230914.docx" for details.

UNISIG 02/10/14We think that is important to get the operational/ergonomics experts feedback on ERA solution proposal.We need their opinion on whether the solution proposed by ERA addresses the problem in an appropriate way.For instance, the solution proposed by ERA can lead to the following effects :- It is still possible that the pre-indication of a target is masked by an earlier target. E.g. if the indication limit of target 2 is a very short distance in advance of target 1, then this target 2 will not be considered as masked by target 1. Upon passing target 1, the driver may release the brakes and may then have to immediately apply the brakes again when the indication limit of target 2 is passed. Therefore the problem flagged by the CR may not be fully resolved

i.e. from the problem description, “drivers may release the brakes on the approach to target 1 having achieved 25kph. In some situations, even if the driver observes and reacts to the change in MRDT immediately there is insufficient time for the brakes to react and an intervention is inevitable.” - If a target is masking a further target, then it would mean that the target speed and distance for the first target are not displayed at all. This might be strange for the driver from an operational point of view.- An LX indication might be given far earlier than expected by trackside or driver (see SRS 5.16.1.4 a), due to the fact that the LX target is considered to be masked by an earlier target i.e. the LX becomes MRDT far earlier than trackside/driver may have expected.

EUG 02/10/14We still believe that the EUG approach to display several targets is better than the one proposed by ERA. We think that the shortcomings detected in the EUG proposal can be solved with some fine tuning of the solution.See attachment <140930_EUGcomm_ERA solCR1084>

EECT 08/10/14Regarding the U comments dated 02/10/14: they are actually only observations and do not challenge the ERA proposal 23/09/14.- Masking of a pre-indication of a target which is not masked: it is recalled that what really matters for the driver is that the indication relative to a target is given in due time. This is why it has been used in the masking criterion proposed by the EUG, which has been on purpose retained.- Target which is not displayed at all because masking the MRDT: the concept of most Relevant displayed target means conversely that the first (masking) target is indeed not relevant for the driver and in addition it will only cause a small step with constant permitted speed.- Indication of the LX not protected icon: U recognizes that the term “far earlier” is a bit excessive. Actually, it just a few seconds earlier to the extent of how close to each other are the two targets. This is however predictable by the trackside and should the LX not protected information sent preventively to the on-board in order to be revoked by the balise group connected to the LX before the pre-indication is passed (in case the LX is protected), this constraint must be taken into accoujnt by the trackside engineering.

Regarding the EUG input 02/10/14, see attachment "EUGcomm_CR1084_ERAreply_081014.docx" for the ERA replies.

In the course of the discussion, it has also been questioned whether CSG color will yellow or not when the train will pass the small constant P-speed step between the two targets. U wonders whether the DMI indication should not remain yellow all along the braking process, as it might be not desirable to have the yellow indication disappearing and re-appearing again.

ERA will check the CSG colour sequence while crossing the intermediate speed step.EUG will reconsider whether the ERA solution proposal is

acceptable.

ERA 27/10/14After a careful check of the SRS section 3.13.10.4, it appears that the indication status will not be revoked during the small constant P-speed step, because in the revocation condition r2 (table 10 or 11) it is stipulated "(only in case of change of displayed target)" while thanks to proposed algorithm there is no change of displayed target.

EECT 04/11/14EUG agrees with the ERA proposal 23/09/14 and UNISIG confirms the ERA analysis 27/10/14 regarding the CSG colour sequence while crossing the intermediate speed step.However UNISIG presents a paper (see attachment "CR1084 LX scenario.docx") which highlights that the proposed solution could well induce for a specific trackside configuration a too early display of the unprotected LX icon.A possibility is to change the criterion to start the display of the unprotected LX icon (clause 5.16.1.4) to specify that it is the crossing of the I supervision limit of the LX EOA/SvL, instead of this latter becoming the MRDT.

ERA 18/11/14The scenario highlighted by UNISIG on 04/11/14 relies on an assumption (“The onboard is systematically provided with LX Unprotected information whenever the MA is extended through the LX”) which is in our opinion wrong. It has been indeed clearly demonstrated in the frame of the CR745 (Permitted braking distance) that such early sending of the LX unprotected info, which is due to the fact that the switchable BG_LX is in general too close to the LX even for well braking trains, should be avoided by using the PBD SR functionality.Actually, with the depicted trackside configuration, the first figure in the attachment "CR1084 LX scenario.docx" just underlines in another way the shortcoming spotted by this CR in the current specifications, i.e. a too late display the LX target information, together with the LX unprotected icon.Therefore we confirm that the ERA solution proposal 23/09/14 need not to be amended and is fit for purpose.

EUG 19-11-2014See attachment "CR1084 EUG proposal 20141119" for our evaluation of the UNISIG concerns raised on 04/11 and the ERA input on 18/11.

UNISIG 26/11/14Regarding ERA’s posting dated 18/11/14:The PBD SR function seems difficult to use to perfection for instance for the supervision of an LX in L2/3. The RBC does not master the exact moment the “LX not protected” information is received on-board. The permitted braking distance to be provided in the PBD SR info could therefore be difficult to engineer with precision.

Regarding EUG’s posting dated 19/11/14: see Word comments in attached file "CR1084 EUG proposal 20141119_SG 20141125.docx".

EECT 03/12/14Regarding the UNISIG comments on the “EUG solution proposal 19-11-2014”: - It is confirmed by EUG that an RBC sending first the “LX unprotected” when an MA is extended over the LX and then “LX protected” on the approach of the LX is actually a used configuration (including a possible speed step in the vicinity of the LX), this avoids the necessity to wait the positive information of the LX status protected as a condition to extend the MA beyond the LX start location. By doing so, both ERA and UNISIG still consider that it would be possible to send only the actual LX status at the appropriate time avoiding this first sending of an always “LX unprotected” information. - 1st step of EUG proposal: EUG explains that it is actually the intention of their following note. They think that the steps 2 and 3 can be systematically applied without checking whether the targets are masked or not. - Assumption “After PI2 the LX target will have disappeared (assuming that the LX is protected by that time)”: It is confirmed that the EUG ideas do not solve the LX not protected early indication. It could still be displayed much earlier than with the current SRS specification - EUG statement “It also gives the driver better information of what is actually happening (two separate targets)”: The UNISIG concern is confirmed. The driver’s indication will indeed change from target 1 to target 2 at a location which is meaningless for the driver (i.e. without having the displayed target distance decreasing till zero). Especially with a freight train, the driver will adapt his speed to respect the target 1 and release the brakes well before reaching the target 1 location. He will then be surprised by this sudden change to target 2 while with the ERA original proposal, he will be able to adapt smoothly to the most Relevant displayed target which is undoubtedly the target 2. ERA also recalls what was already stated in the October EECT that there is no negative performance impact since the driver primarily must start to brake according to I and P display on the DMI, not according to the target speed/distance display (The P-curve that must be followed by the driver will remain unchanged).

Based on the above, EUG to check and possibly reconsider their ideas (see attachment "CR1084 EUG proposal 20141119") and ERA to evaluate again a possible modification to the clause 5.16.1.4 to change the criterion to start the display of the unprotected LX icon.

ERA 17/12/14See updated solution proposal in attachment "ERA_solution_proposal_for_CR1084_171214.docx" for the modification to clause 5.16.1.4.

EUG 06/01/15Trafikverket confirmed that they could accept to change their RBC functionality according to ERA assumption that MA first shall be sent to the LX and then prolonged first when the LX is protected, i.e. no LX packet is used in normal case. Only when the LX is not protected in due time a LX packet with not protected shall be sent. However we still have the following concerns with the ERA solution

proposal. See CR1084_EUGcomm_150106

EECT 13/01/15UNISIG confirms that the enhancement for the display of the LX icon (ERA proposal 17/12/14) is OK. At first sight, this would also make the Trafikverket statement (06/01/15) that they accept to re-engineer the RBC for the LX scenario useless, however EUG needs to double check it.

Regarding the batch of EUG questions for the LX scenario (06/01/15), ERA clarifies that the assumption in item a), on which all the other questions are based, is wrong,see attachment "CR1084_EUGcomm_150106_withERAreplies.docx".

With the enhancement for the display of the LX icon, the ERA solution proposal 17/12/14 forms a robust and fine tuned solution to the problem raised by this CR, while the EUG ideas to display the two consecutive targets, the second one interrupting the display of the first one, remains to be comprehensively specified and needs to be balanced from ergonomic/operational point of view against the display of the hidden target only (ERA solution).EUG to check if the ERA enhanced proposal (17/12/14) is OK, to check the replies to the batch of questions raised on 06/01/15 and to benchmark from ergonomic/operational point of view the ERA solution vs their approach.

EUG 04-02-2015Regarding the updated ERA proposal we have no technical questions.Regarding the replies on the questions raised beginning of January we have no further comment.Regarding the ergonomic/operational aspect of the 2 solutions we have the following remark.We checked with some drivers the ergonomic aspect of these solutions and the result is that in principle both are acceptable. We have however one issue which is more than just driver ergonomics. In the ERA proposal the second target appears earlier than in the alternative proposal (and earlier than in the current spec). If the second target is an EOA then, in case the MA is extended in the approach to the first target, the driver would always see an EOA (a red signal) for a few seconds, after which it disappears. This is clearly not what should happen in a well designed line. To avoid this the engineering of the line should take this behaviour into account, but that would complicate the engineering, which is already complicated when there is a speed restriction close to the EOA. This impact on engineering is there in the EUG solution. But it is still less restrictive than the ERA solution. From an engineering point of view the EUG solution is therefore better.

ERA 02/06/15In the light of the CR1249 the solution proposal is updated (see parts highlighted in blue in the attachment "ERA_solution_proposal_for_CR1084_020615.docx") according to the following directions:1) the selection of the MRDT takes into account only the targets

whose indication supervision limit is passed. This automatically resolves the EUG concerns on 04/02/15 since the EOA will enter into play only if its indication is crossed before the MA is renewed.2) for the same reason, the modifications to chapter 5 for the sake of the LX symbol display are withdrawn, because no longer needed.

In addition, the criterion to decide whether a target is masked is refined to use the foot of the MRDT P supervision limit instead of the MRDT location itself. This is useful when the indication supervision limit of the second target is in located in between the P foot and the first target, but also especially in case of SB feedback functionality active: otherwise it would be possible not to select the second target as masked because of the reduction of Tbs and to have already passed the indication of the second target when the first target is passed.

EECT 10/06/15The ERA solution proposal 02/06/15 is slightly amended with the following editorial comments in 3.13.10.4.2 (see attachment "ERA_solution_proposal_for_CR1084_EECT100615.docx"): - UNISIG comment on step 0: ellipsis (i.e. "...") shall be used for the formulas to explicitly mention that the calculation is made from targets 1 to N - UNISIG comment on step 1: missing "or" in the formulas to explicit state that the calculation goes from targets 1 to N - EUG comment on step 1: split the second sentence in two sentences by removing the "and" following MRDT0.

In addition, UNISIG tables the following concerns: - What is meant by these targets "have been met" in 3.13.10.4.2? If the indication supervision limit is no longer passed (e.g. due to braking) for a target, UNISIG considers that the concerned target shall remain in the list as otherwise there could be fluctuations in the DMI. ERA answers that the solution proposal has been designed in such a way that only targets for which indication limits are passed are considered i.e. in such situation as depicted by UNISIG, the target would be removed from the list but the clause 3.13.10.4.5 was intended to keep this target as MRDT. However in case of masked target, the resulting behaviour from the current proposal needs to be further investigated. - Once the EOA/SvL is selected as MRDT, the wording “if MRDT0 is neither the EOA nor the SvL” in step 1 does not seem to be applicable. It is consequently unclear how to read 3.13.10.4.2 once the EOA/SvL is selected as MRDT.

ERA 01/07/15See updated solution proposal (parts highlighted in blue) in attachment "ERA_solution_proposal_for_CR1084_010715.docx", which addresses the editorial comments and the UNISIG concerns raised in EECT 10/06/15.Regarding the second concern expressed by UNISIG, it is actually superseded by the necessity to fix a flaw in the solution proposal not detected so far: once a target is selected as MRDT, only other targets below this MRDT can be checked whether they are masked or not, since there is no indication supervision limit below a target speed.

EECT 08/07/15The UNISIG review comments against the ERA solution proposal 01/07/15 are discussed. With the exception of comment #4 (the remarks stands for all the other equations in the SRS and will be possibly taken into account when the SRS documents will be migrated to the “docx” format), all the UNISIG comments are accepted, see parts highlighted in yellow in the attachment "ERA_solution_proposal_for_CR1084_010715_EECT.docx".Regarding the UNISIG comment #5, the wording of the clause 3.13.10.4.5 is refined to clarify that there is only one target displayed at a time, the MRDT. Actually the clause 3.13.10.4.5 has to be read as a complement of the clause 3.13.10.4.2.EUG informs that they had no comment against the ERA solution proposal 01/07/15 and that they intend to produce videos of the technical solution and will make them available for a better validation.In the meantime, the ERA solution proposal 01/07/15 amended with the above modifications, is agreed, see attachment "ERA_solution_for_CR1084_080715.docx" for details.

EECT 08/12/15The two following remarks regarding clause 3.13.10.4.2 are taken into account: - the former formula where the variable V_P_MRDT has been replaced with V_P_MRDT_0 does not appear as being deleted. - in Step 1, last paragraph: according to a professional translator (native English speaker), the term ‘the most in rear of’ is not correct English. It should rather say ‘the furthest in rear of’.See parts highlighted in blue in the attachment "ERA_solution_for_CR1084_111215.docx" in the field "Agreed solution"

Supporting document(s) for Justification/Discussion for Solution

ERA_solution_proposal_for_CR1084_230914.docx140930_EUGcomm_ERA solCR1084.docxEUGcomm_CR1084_ERAreply_081014.docxCR1084 LX scenario.docxCR1084 EUG proposal 20141119.docxCR1084 EUG proposal 20141119_SG 20141125.docxERA_solution_proposal_for_CR1084_171214.docxCR1084_EUGcomm_150106.docxCR1084_EUGcomm_150106_withERAreplies.docxERA_solution_proposal_for_CR1084_020615.docxERA_solution_proposal_for_CR1084_EECT100615.docxERA_solution_proposal_for_CR1084_010715.docxERA_solution_proposal_for_CR1084_010715_EECT.docxERA_solution_for_CR1084_080715.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

EEIG (ERTMS users group)

Contact person name R. DijkmanContact Person e-mail adress rdijkman@ertms.beEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number EEIG382List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassification

There is no gap/inconsistency in the current SRS regarding the display of target information

Reason for rejectionReason for postponement Problem description deserves further investigations.

Any solution deviating from the existing situation would consist of a significant increase of complexity of the BC model, which is anyway questionable as long as more feedback is not collected regarding the braking curve model

Superseding CRList of superseded CRs Date of Submission 2011-06-08 06:53:31 PMLast modification date 2016-01-06 04:10:52 PM

Identification number 1086State Presented_to_ECHeadline Unknown L1 LRBG reported to RBCImpacted System ETCSReference Baseline Release Baseline 3 (2nd consolidation release 12/2010)Documents and/or References SUBSET-026 V320Error/Enhancement EnhancementProblem/Need description 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 EEIG384 attachment.doc

problem/need descriptionSolution Proposal by submitter Please answer the 2 questions in the problem description.Supporting document(s) for solution proposalAgreed Solution 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 the RBC has received from the onboard an unknown position (as per 3.6.2.2.2.1) or during SoM procedure 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 solutionJustification/Discussion for Solution

ERA 14/08/14Question 1: We cannot see any sound reason why an RBC should trigger severe RBC reactions when a reported LRBG is not known in its data preparation. In particular, an unknown LRBG leading to an RBC crash can only be seen as an unsuitable product design.

Question 2: Amongst the 4 proposed alternatives, we confirm that the second one is the best one which is retained for the following proposal i.e. the RBC must be able to deal with the fact that it does not know all reported LRBGs by the train. To send messages to the train, it has to use the last LRBG reported by the train which it knows. This implies that paragraph 3.6.2.2.2 b) of the SRS, stating that the RBC shall use the last reported LRBG by the train shall be amended.

See attachment "ERA_solution_proposal_for_CR1086.docx" for the details.

UNISIG 30/08/14The ERA solution proposal posted on 14/08/14 does not specify what the RBC is authorized to use as LRBG in case it does not know the last received LRBG from the on-board. We see this as a miss of the solution proposal. We propose a solution that addresses this point (see attachment "SG solution proposal for CR1086 - 20140830.docx").

EUG 02-09-2014This reply refers to the ERA proposal om 14/08/14. We did not check the UNISIG entry on 29/08.We believe that the modified clause 3.6.2.2.2b can still be interpreted as solution 4 in the EEIG384 attachment. We discussed potential improvements of the text and we came to the conclusion that in fact there is no basis for the restriction of the RBC to take

always the last of the (known) BGs as a reference. The RBC knows that the onboard is able to remember the last 8 BGs and that is sufficient for the RBC to make its own decision on which BG to use as a reference. That brings us to the following functional needs.1) The RBC shall be able to handle unknown BGs in the position reports of the onboard, i.e. no crash or anything like that.2) No restriction for the RBC to use a specific BG as a reference. It should be allowed to use both known and unknown BGs according to its own decision. (Of course this decision should be based among others on the above mentioned requirement that the onboard remembers at least 8 BGs.)

Rationale• For sending messages with location dependant information like an MA or a CES the RBC will (obviously) only use known BGs as location reference. This known BG might not be the last relevant balise group reported to the RBC. Therefore the RBC shall not be restricted to use the last relevant balise group reported to the RBC as location reference.• For sending messages with location independant information, like an UES, the RBC might use known or unknown BGs as LRBG. There is no need to restrict the RBC to use only known BGs as location reference. The BG might or might not be the last relevant balise group reported to the RBC. Therefore the RBC shall not be restricted to use the last relevant balise group reported to the RBC as location reference.

These requirements should be the basis for the solution in this CR.

EECT 09/09/14Regarding the UNISIG remark 30/08/14: the supposed miss (what the RBC is authorized to use as LRBG in case it does not know the last received LRBG from the on-board) is addressed with a non requirement in the UNISIG attachment "SG solution proposal for CR1086 - 20140830.docx".The ERA proposal was indeed meant to leave full freedom to the RBC when it does not know the LRBG reported by the on-board. On the other hand UNISIG would like to restrict this freedom exclusively either to the re-use of the LRBG not known to the RBC (presumably for non location based messages) or to the use of the LAST known LRBG to the RBC.

EUG 18-09-2014We can agree the principle written in the last sentence of the EECT entry. However we have a concern: the principle allows to go back in the sequence of LRBGs (from the unknown LRBG to a previous known LRBG). We understood that this was one of the concerns of UNISIG. Are on-boards capable to manage this situation? In case the answer is no we have to analyse the compatibility with existing on-boards.

ERA 30/09/14See updated solution proposal in attachment "Solution_proposal_for_CR1086_300914.docx", which implements the principle written in the last sentence of the EECT entry 09/09/14 as a testable requirement consisting of a true exception to 3.6.2.2.2

b).Regarding the EUG concern about the capability of on-boards to handle this principle which allows going back in the sequence of LRBGs: an on-board that would not handle this situation would not be compliant with the clause 3.6.2.2.2 c), which in our opinion does not suffer from any kind of ambiguity.

EECT 08/10/14UNISIG considers that the freedom to repeat the LRBG not known to the RBC or to use the LAST known LRBG to the RBC for non location based messages is not in the updated proposal (see attachment "Solution_proposal_for_CR1086_300914.docx). They consider this latter is not is fully in line with the principle established in the last EECT meeting, which looks to have been not interpreted the same way by ERA.ERA remarks also that with this additional freedom, we move a bit further away from the current specification (always use the last reported LRBG) and get very close to the original ERA proposal (posted 14/08/14) which gave full freedom to the RBC when the LRBG is not known to the RBC, no matter the type of information (location or not location based).Regarding the EUG concern (18/09/14) about the capability of on-boards to handle this principle which allows going back in the sequence of LRBGs: UNISIG confirms the ERA statement that an on-board that would not handle this situation would not be compliant with the clause 3.6.2.2.2 c).UNISIG to reconsider if either the ERA proposal in attachment "Solution_proposal_for_CR1086_300914.docx" or the original proposal tabled on 14/08/14 is acceptable.If this latter comes back to live, it is already accepted to retain the proposed move of the terrm “during SoM procedure” in clause 3.6.2.2.2.2, as previously proposed by UNISIG.

UNISIG 31/10/14We have reconsidered both the ERA proposal in attachment "Solution_proposal_for_CR1086_300914.docx" and the ERA original proposal tabled on 14/08/14. In this reconsideration, we came (again) to the fundamental question: what is the reason for forcing the RBC to use the LAST relevant balise group (LRBGONB) it received from the on-board? The only reason we see is to have the highest chance that the reference the RBC uses is in the on-board list of the last 8 reported LRBGs. We however consider this as a weak reason because an on-board is able to accept any reference among the last 8 reported LRBGs, i.e. not only the last reported one, and a trackside design has to consider anyway this limit of 8. The ERA proposal in attachment "Solution_proposal_for_CR1086_300914.docx" keeps the principle of using the last received LRBGONB and relaxes it only for the messages that contain location based data and that have to be sent after the reception of an LRBGONB not known to the RBC. It however forces the RBC to use the last received LRBGONB it knows. As explained above, we do not see the real need to enforce the RBC

to use the most recent possible reference. The original ERA proposal tabled on 14/08/14 relaxes the requirement for any message to be sent after the reception of an LRBGONB not known to the RBC. We consider this proposal as going in the right direction but not going far enough. We are in favour of completely relaxing requirement 3.6.2.2.2 b), this way the RBC decides itself which LRBG to use. This is the principle supporting our new proposal (see attachment “SG solution proposal for CR1086 - 20141030.docx”). Note: this new proposal includes the move of the term “during SoM procedure” in clause 3.6.2.2.2.2 according to 08/10/14 EECT meeting conclusions. It also deletes the comma between “position” and “or” in this clause 3.6.2.2.2.2.

EECT 04/11/14The updated UNISIG solution proposal (30/10/14) is agreed.

EECT 08/12/15The shift of the term “during SoM procedure” in clause 3.6.2.2.2.2 is potentially problematic. Actually it excludes the case of an on-board sending a PR with unknown position outside SoM context (e.g. with pck 136 after a post SoM manual change to level 2/3).It is therefore agreed to rephrase 3.6.2.2.2.2 as follows: “When the RBC has received from the onboard an unknown position (as per 3.6.2.2.2.1) or during SoM procedure an invalid position which it is not able to confirm......”

Supporting document(s) for Justification/Discussion for Solution

ERA_solution_proposal_for_CR1086.docxSG solution proposal for CR1086 - 20140830.docxSolution_proposal_for_CR1086_300914.docxSG solution proposal for CR1086 - 20141030.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

EEIG (ERTMS users group)

Contact person name R. DijkmanContact Person e-mail adress rdijkman@ertms.beEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number EEIG384List of assigned WG(s)Severity Performances impact, non interoperability and non safety relatedTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassification

There is no gap/inconsistency in the specification regarding the concerned functionality.

Reason for rejection

Reason for postponement While the solution alternative 2 seems to be the soundest one, this discussion may take place in the frame of a further (compatible) baseline

Superseding CRList of superseded CRs Date of Submission 2011-06-08 07:15:14 PMLast modification date 2016-01-06 04:10:53 PM

Identification number 1087State Presented_to_ECHeadline Manual network selectionImpacted System ETCSReference Baseline Release Baseline 3 (2nd consolidation release 12/2010)Documents and/or References SUBSET-026 V320

ERA_ERTMS_015560, V3.2.0Error/Enhancement EnhancementProblem/Need description 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.

Supporting document(s) for problem/need descriptionSolution Proposal by submitter Make it possible for the driver to select the right network in any level.Supporting document(s) for solution proposalAgreed Solution Modify SUBSET-026 v3.4.0, SUBSET-027 v3.1.0 and

ERA_ERTMS_015560 v3.4.0 as described in the attachment "ERA_Solution_for_CR1087_111215.docx"

Supporting document(s) for agreed solution

ERA_Solution_for_CR1087_111215.docx

Justification/Discussion for Solution

UNISIG 01/04/15See attachment "Solution proposal for CR 1087_v1.4.docx" for a solution proposal.

EUG 08/04/15UNISIG solution proposal agreed.

EECT 15/04/15Although the UNISIG solution proposal 01/04/15 has been agreed by EUG (08/04/15), ERA underlines that the solution proposal (a duplicated data entry window accessible through different buttons in different menus) is not at all in line with the ergonomic principles of the current DMI specification. In particular, UNISIG is unable to properly justify why they opted for this new button “Radio network change” in the “Special” menu window that leads to a new “Radio

network change in level 0/1/NTC” data entry window duplicating the “RBC network ID” window: as described in the problem/need description, the situation addressed by this CR is common operational practice.It is also surprising that UNISIG does not claim that, like for other similar CRs “the ergonomics experts and operational experts have to be consulted before an agreement can be reached on the principles of the solution proposed”, while this CR has obvious operational/ergonomic impacts.Finally, it is agreed during the meeting that the radio network data entry window should be accessible regardless of the level. Moreover, its selection button should either be fully separated from the RBC related buttons or at least, the “RBC contact” window be renamed to “Radio contact” because U spots that in L1 radio infill it should also be possible to change the radio network.These detailed ergonomic arrangements will be defined by the ERA DMI WG and therefore the CR is taken over by ERA in order to redraft the solution proposal.

ERA 30/04/15See attachment "ERA_Solution_proposal_for_CR1087_300415.docx".

EUG 06-05-2015The ERA proposal looks OK. We have just one small question. In the DMI part, table 37, row 4, you introduce as SRS references 3.18.4.3.6 and 5.4.5.3 k. We were not able to find these clauses, neither in the SRS340, nor in the 1087 solution proposal. Can you clarify?

EECT 13/05/15The comments on the ERA solution proposal 30/04/15 are reviewed, see attachment "ERA_Solution_proposal_for_CR1087_EECT130515.docx"Only the reply to UNISIG comment #1 is not agreed by UNISIG. However, the CR is closed (ERA decision) with the amendments as per agreed comments.

ERA 19/10/15The solution proposal needs to be revisited to address the following issues:- To avoid any ambiguity on the fact that an invalid RBC id should not lead to any check from the EURORADIO when using the short number, the RBC id/phone number is set to unknown in such a case.- The CR1267 problem description highlights that the MT shall be in “command” state to be able to acquire the list of available and allowed networks. It is therefore proposed to terminate the communication session prior to the acquisition of the radio networks (and not after).- The SUBSET-027 impact has been overlooked.- Clause 3.5.6.4 is obsolete since the radio network can be changed also outside the SoM procedure.- Having the "close" button enabled in the "radio network" window during the start up dialogue sequence leads to useless navigation since no other option than coming back to this window will be offered

in the "Radio data" window.- Revalidating a radio network ID is meaningless. This notion is removed from the DMI specification

The additional changes with regards to the previous solution proposal (13/05/15) are highlighted in blue in the attachment "ERA_Solution_proposal_for_CR1087_191015.docx".

UNISIG 23/10/15See attached file "ERA_Solution_proposal_for_CR1087_191015-U.docx" for UNISIG comments on updated solution proposal posted by ERA on 19/10/15.

EECT 03/11/15The review comments from UNISIG (23/10/15) are discussed. The CR is closed with the agreed modifications, see parts highlighted in blue in the attachment "ERA_Solution_proposal_for_CR1087_EECT031115.docx".

EECT 08/12/15The following amendments to the solution 03/11/15 are agreed:

SUBSET-026 part:- 3.5.3.4 h), replace "SoM" with "Start of Mission" - modification to 3.5.5.1 g) to be removed due to CR852 that has deleted the list of conditions- 5.4.3.2 S3 2nd bullet of the first list, the “and” before “if not unknown” should be restored- 5.4.3.2 S3 3rd bullet of the second list, replace "valid or invalid" with "invalid or valid" to match the verbs “revalidate/re-enter”. The 1st bullet of the second list is also to be changed accordingly to have the same wording.- 5.4.5.3 j) : full stop missing after second bullet.DMI part- figure 136, "RBC contact" is replaced with "Radio data" also in steps S3-2-1 and S3-2-3 following the update due to CR1277

See parts highlighted in blue in the attachment "ERA_Solution_for_CR1087_111215.docx" in the field "Agreed Solution"

Supporting document(s) for Justification/Discussion for Solution

Solution proposal for CR 1087_v1.4.docxERA_Solution_proposal_for_CR1087_300415.docxERA_Solution_proposal_for_CR1087_EECT130515.docxERA_Solution_proposal_for_CR1087_191015.docxERA_Solution_proposal_for_CR1087_191015-U.docxERA_Solution_proposal_for_CR1087_EECT031115.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

EEIG (ERTMS users group)

Contact person name R. DijkmanContact Person e-mail adress rdijkman@ertms.beEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number EEIG385List of assigned WG(s)Severity Performances impact, non interoperability and non safety relatedTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassification

This CR consists of a functional enhancement aiming to cope with an inadequation between the trackside engineering and the way the trains are awaked (or vice-versa).

Reason for rejectionReason for postponement There is no time left in the frame of the baseline 3 programme to

undertake technical discussions and to possibly derive a solution for this CR.

Superseding CRList of superseded CRs Date of Submission 2011-06-08 07:18:26 PMLast modification date 2016-01-06 04:10:53 PM

Identification number 1089State Presented_to_ECHeadline Ack for text messages in NL modeImpacted System ETCSReference Baseline Release Baseline 3 (2nd consolidation release 12/2010)Documents and/or References SUBSET-026 v3.2.0, 3.12.3, 4.5.2Error/Enhancement EnhancementProblem/Need description 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 acknowledgement, this can lead to unwanted situations.

Remark: The issue has been analysed in the OH WG, see supporting document "OH proposal Ack for text messages in NL v1.doc"

Supporting document(s) for problem/need description

OH proposal Ack for text messages in NL v1.doc

Solution Proposal by submitter It is proposed to inhibit the function “Manage Text Display to the driver” in NL mode

Supporting document(s) for solution proposalAgreed Solution 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.4Replace 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 solutionJustification/Discussion for Solution

ERA 14/08/14See attachment "ERA_solution_proposal_for_CR1089.docx" for the detailed solution proposal.

UNISIG 29/08/14See attachement "Unisig_SG_COM_CR1089 - 20140829" for UNISIG comment on ERA solution proposal posted on 14/08/14.

EUG 29-08-2014We support in principle the analysis and conclusion of OH, which is reflected in the ERA solution proposal. We have just one clarification question. The purpose of this CR is to avoid showing in NL mode trackside text messages which have to be acknowledged by the driver. This is achieved by deleting the line "Manage Text Display to the driver" in SRS 4.5.2. The question is what will happen with the system messages. DMI 15.1.1.4 says that they shall be displayed as text messages. From that statement we could understand that they are included in the text management which has just been deleted from SRS 4.5.2. The line in 4.5.2 refers to SRS 3.12.3, which is the trackside text messages, but since there is no other specific management of system messages listed in 4.5.2 this could lead to misunderstandings. So the question is whether the OH intentionally wanted to delete also the system messages in NL, yes or no. In both cases we think that the SRS and/or DMI spec could use some clarification.Note that our final agreement will only be given after the compatibility assessment.

EECT 09/09/14Regarding the remark posted by EUG (29-08-2014): ERA underlines that there is no specific line in table 4.5.2 for the system status messages, because the system status messages do no consist of a function as such and are rather part of various other functions as referred to in the table 4.7.2 => it is also confirmed by UNISIG that no confusion is possible.The ERA solution proposal posted on 14/08/14 is therefore agreed.

Supporting document(s) for Justification/Discussion for Solution

ERA_solution_proposal_for_CR1089.docxUnisig_SG_COM_CR1089 - 20140829.doc

Preliminary Assessment of Benefits

Supporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

ERA (European Railway Agency)

Contact person name A. HougardyContact Person e-mail adress alain.hougardy@era.europa.euEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number List of assigned WG(s)Severity Interoperability and non safety relatedTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassification

The CR does not demonstrate any gap/inconsistency in the specifications

Reason for rejectionReason for postponement This ergonomic issue can be resolved in a further (compatible)

baseline.Superseding CRList of superseded CRs Date of Submission 2011-06-20 12:45:59 PMLast modification date 2016-01-06 04:10:53 PM

Identification number 1091State Presented_to_ECHeadline Insufficient driver information in OSImpacted System ETCSReference Baseline Release Baseline 3 (2nd consolidation release 12/2010)Documents and/or References SUBSET-026 V320

ERA_ERTMS_015560, V3.2.0Error/Enhancement EnhancementProblem/Need description 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/14The above problem/need description is fully replaced with the following one:

The ERTMS specifications provide the possibility to show basic

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 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 descriptionSolution Proposal by submitter To help the driver recognise speed restrictions quickly and/or in

advance, the planning area shall be available also in OS mode with the condition that the driver shall be able to toggle it on and off.

Change the SRS as follows:Include in 4.4.12.1.4 the planning area as one of the items to display on drivers request.

Change the DMI specification as follows:8.2.2.4.4 OS mode: add "Planning area". 8.3.1.1 The planning information shall be shown in area D (see figure 72) according to the following conditions: a) it is available, andb) the current mode is FS or OS (see 8.2.2.4.for the toggle condition in OS), and c) its status is “show planning information” (see 8.3.9)8.3.9.8 When entering FS mode, the status of the planning information stored onboard shall be used.

Note: If necessary the DMI WG may consider adaptation of the Planning area in OS mode (e.g. different background) to emphasise the difference between OS and FS mode.

Supporting document(s) for solution proposalAgreed Solution Modifiy SUBSET-026 v3.4.0 and ERA_ERTMS_015560 v3.4.0 as

described in the attachment

"ERA_solution_for_CR1091_260515.docx"Supporting document(s) for agreed solution

ERA_solution_for_CR1091_260515.docx

Justification/Discussion for Solution

ERA 14/08/14While the basic need of the CR is acknowledged (reducing as much as possible the time the driver “checks the DMI rather than the track occupancy)”, it seems that the main argument of the submitter (“The driver needs to constantly check the DMI for any upcoming speed supervision information”) is annihilated by the primary purpose of the sound Sinfo, which is played each time the pre-indication location of a target is passed: “Audible information is used to draw the driver’s attention from the outside to the display” (see ERA_ERTMS_155560 § 14.1.1.1).Even after the driver’s attention has been drawn by the Sinfo, it is debatable whether the enabling the planning info in OS would be helpful and this is why the CR first deserves further investigations by operational experts, before the solution proposed by the submitter can be confirmed as addressing the need expressed in the CR. 1. For a proper supervision, each target could anyway need detailed information only available in the areas A/B, since the planning information only gives an abstract of the advance route related information and more specifically of the speed restrictions which will not help so much in terms of supervision2. Adding the planning information could have the opposite effect of having the driver focussing too much on the DMI information instead of looking outside,3. A fair balance still need to be found between DMI objects displayed in SR, OS and FS modes

ERA 26/05/15As a result of the revised problem description (30/09/14), see attachment "ERA_solution_proposal_for_CR1091_260515.docx" for a detailed solution proposal.

EUG 02/06/15ERA solution proposal "ERA_solution_proposal_for_CR1091_260515.docx" is agreed by EUG.

UNISIG 03/06/15ERA solution proposal posted on 26/05/15 is agreed.

Supporting document(s) for Justification/Discussion for Solution

ERA_solution_proposal_for_CR1091_260515.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

EEIG (ERTMS users group)

Contact person name R. DijkmanContact Person e-mail adress rdijkman@ertms.be

Endorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number EEIG376List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassification

There is no demonstration of a gap/inconsistency in the current specifications

Reason for rejectionReason for postponement See reason for postponement of CR1107, which is a prerequisite for

this CR.Superseding CRList of superseded CRs Date of Submission 2011-07-21 06:14:19 PMLast modification date 2016-01-06 04:10:53 PM

Identification number 1094State Presented_to_ECHeadline Unclear stop conditions for display of some DMI objectsImpacted System ETCSReference Baseline Release Baseline 3 (2nd consolidation release 12/2010)Documents and/or References SUBSET-026 v3.2.0, ERA_ERTMS_015560 v3.2.0Error/Enhancement ErrorProblem/Need description 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)- 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 descriptionSolution Proposal by submitter Define the stop condition either in the SRS or in the DMI spec as

follows:

For the missing stop conditions:- Trackside malfunction: displayed during xx seconds- Trackside not compatible: displayed during xx seconds- Radio network registration failed: option 1, removed from the DMI when the driver selects another button on the 'Main' window or option 2, removed following xx seconds- SH refused: option 1, removed from the DMI when the driver

selects another button on the 'Main' window or option 2, removed following xx seconds- SH request failed: option 1, removed from the DMI when the driver selects another button on the 'Main' window or option 2, removed following xx seconds- Train data changed (without brake reaction): displayed during xx seconds- Train is rejected: option 1, removed from the DMI when the driver selects another button on the 'Main' window or option 2, removed following xx seconds

For the unappropriate stop condition:- Communication error (case of service brake command): apply SRS 3.14.1.7 "if a new consistent message has been received from the RBC" for stopping the display but display "Communication error" for at least xx seconds (note: the timer is introduced to give enough time to the driver to diagnose the reason of the brake command for the case the new consistent message is received just after the T_NVCONTACT reaction i.e. it avoids having a glitch on the DMI for the brake reason)

Supporting document(s) for solution proposalAgreed Solution 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_111215.docx"

Supporting document(s) for agreed solution

ERA_Solution_for_CR1094_111215.docx

Justification/Discussion for Solution

ERA 20/11/14See attachment "ERA_solution_proposal_for_CR1094_201114.docx" for detailed solution proposal.

EUG 28-11-2014In principle we agree with the ERA proposal.For the message "emergency stop" the conditions reflect the ERA 17/11 proposed solution of CR1190. Our final agreement for this is of course pending the conclusion for CR1190.

UNISIG 28/11/14See attachment "ERA_solution_proposal_for_CR1094_201114_SG.docx" for UNISIG review comments on ERA solution proposal posted on the 20/11/14 (review comments appear as Word comments in this attachment).

EECT 03/12/14Based on the UNISIG comments, on the position of the ergonomic expert of the ERA OH WG for what regards the time related display end conditions (30s instead of 60s as proposed by ERA) and on the position of the CER/EIM experts of the ERA OH WG for what regards the CR1190, the ERA solution proposal 20/11/14 is agreed with the following amendments:- All occurrences of 60s are replaced with 30s- comment#1: it is agreed to add an additional time of display (30s) for all the end conditions 3.14.1.6 (brakes released at standstill), the

main rationale being the fact that the balise read error may happen at low speed, which then would lead to a too short display time- comments #6&7: reference replaced with 3.14.1.7.4- comment #10: an additional end condition is added, corresponding to the case of a replacement (per type of route suitability) with a value of the concerned parameter which does no longer lead to an incompatibility

See attachment "ERA_solution_proposal_for_CR1094_031214_EECT.docx" for the updated solution proposal which also contains the replies to the other (rejected) UNISIG comments.

ERA 18/12/14See parts highlighted in yellow and modification to SUBSET-035 in attachment"ERA_Solution_proposal_for_CR1094_181214.docx" for updated solution proposal, further to an interaction with CR1242 item #14.

EECT 13/01/15The following UNISIG questions are addressed: - Regarding the line “NTC failed“ in table 4.7.2, which applicable modes were not specified at all in the SUBSET-035: the absence of display in RV is made on purpose because an acknowledgment would be requested to the driver and it is a general approach not to disturb the driver while he is performing a reversing operation in RV mode - Removal of “i.e. when the Train Data button is pressed” in clause 10.7.3.5: there is nowhere else than in the DMI spec mentions to the ETCS DMI buttons - Regarding the column “end condition” and in particular for the lines “route suitability”, it is clarified that the different end conditions separated by commas are exclusive and can therefore not be understood as subconditions to be fulfilled all together. It is therefore not needed to create sublines per end condition. Nevertheless, for the lines “route suitability”, it is agreed not to use the term “and” in the last end condition.

The ERA solution proposal 18/12/14 is agreed with the following amendments to the lines related to route suitability: - replace "and" with "with" in the third stop condition for the three Route suitability lines - wrong reference corrected in the two last linesSee attachment "ERA_Solution_for_CR1094_130115.docx" for details.

EECT 08/12/15The following amendments to the solution 13/01/15 are agreed: - the change in the title of table 68 is not properly marked in the CR, only the term “SRS” should be marked as replaced with “SUBSET-26”. The title of table 69 is actually not changed, it should not be indicated with change marks - In tables 68 and 69, there should be a space between value and unit (e.g. "30 s" instead of "30s" (several occurrences))See attachment "ERA_Solution_for_CR1094_111215.docx" in the

field "Agreed Solution"Supporting document(s) for Justification/Discussion for Solution

ERA_solution_proposal_for_CR1094_201114.docxERA_solution_proposal_for_CR1094_201114_SG.docxERA_solution_proposal_for_CR1094_031214_EECT.docxERA_Solution_proposal_for_CR1094_181214.docxERA_Solution_for_CR1094_130115.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

ERA (European Railway Agency)

Contact person name A. HougardyContact Person e-mail adress alain.hougardy@era.europa.euEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponement The filling of this gap is not critical and can be postponed to a further

(compatible) baselineSuperseding CRList of superseded CRs Date of Submission 2011-07-25 07:50:39 PMLast modification date 2016-01-06 04:10:54 PM

Identification number 1107State Presented_to_ECHeadline Status planning information on the DMI in FS modeImpacted System ETCSReference Baseline Release Baseline 3 (2nd consolidation release 12/2010)Documents and/or References SUBSET-026 v3.2.0, 4.7.2

ERA_ERTMS_015560 v3.2.0, 8.3.1.1Error/Enhancement EnhancementProblem/Need description 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 (see attachment "Development of the ETCS MMI.pdf" (A200/M.F5-945222-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.

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_ETF-ALE_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.

Supporting document(s) for problem/need description

Development of the ETCS MMI.pdfLetter_ETF-ALE_planning_area_mandatory.docx

Solution Proposal by submitter Modify SUBSET-026 v320 as follows:Replace in table 4.7.2, on the line “Advance display of route related information” the “O” with an “X” for the “FS” column.

Modify ERA_ERTMS_015560 v320 as follows:Delete 8.3.1.1.a;

Renumber 8.3.1.1.b and c into 8.3.1.1.a and b;Delete 8.3.1.1.1

Remark from submitter:Modifying the above, will not introduce modifications on trackside. It will guarantee a harmonized and consistent picture on the DMI of the information available within the given MASince already in the today’s existing DMI specification from ERA the size of the DMI compromises all area’s as mandatory, the space to show planning information shall always be available and will therefore not require new engineering.

Supporting document(s) for solution proposalAgreed 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

ERA_Solution_for_CR1107_190515.docx

Justification/Discussion for Solution

ERA OH WG 28/09/11See below an extract from the minutes of the OH WG meeting, defining under which conditions this CR and the CR987 will be processed."5.3 Nevertheless all possible effort shall be done in order to study these two possible improvements of the DMI under the condition that the results will not delay baseline 3. It means that the work shall be prepared in such a way that the results are effective at latest at the beginning of December this year. The way to organise the work has been organised during the meeting with consideration to the two different topics: the planning information and the acknowledgement of OS and SR.5.4 It was made clear that these two modifications will be taken into account under the condition that they are unanimously supported by the sector."

ERA 14/08/14Modify SUBSET-026 v3.4.0 as follows:Modify table 4.5.2, row "Advance display of route related information" as follows:Replace "O" with "X" in the column "FS"

Modify ERA_ERTMS_015560 v3.4.0 as follows:Replace clauses 8.3.1.1.a and 8.3.1.1.1 with "Intentionally deleted"

UNISIG 29/08/14The ERA solution proposal posted on 14/08/14 is agreed.

EUG 29-08-2014We support the solution proposal from ERA on 14/08/14.

ERA 01/04/15Considering the arguments given by the submitter in the "field problem/need description" (amongst others: "....planning information provides an essential element of drivers information...."), it is obvious that there is no reason to keep the possibility for the driver to toggle off the display of the planning information.

The solution agreed on 29/08/14 needs therefore to be updated accordingly, see attachment "ERA_Solution_proposal_for_CR1107_230315.docx" for details.

UNISIG 11/05/15We have the following comment on ERA solution proposal posted on 01/04/15:clause 8.3.1.1 c) of ERA_ERTMS_015560 v3.4.0 should also be replaced with “Intentionally deleted”.

EECT 13/05/15Within CER, there is no longer an agreement that the planning info should be mandatory because it can be used by other signalling systems or for redundancy purpose. ERA objects that the D area is not to be confused with the planning info itself since it is used by other mandatory ETCS objects/functions (e.g. Train Data entry). The fact that the planning info was optional however does not make possible such “free shopping list” use of ETCS DMI areas for other purposes than ETCS.In addition ERA recalls that this CR1107 was already agreed in 2014 and that its reopening was due to the overlooking of the toggling function removal.The CR is closed taking into account the UNISIG editorial comment (11/05/15), however without the agreement of the Railways (ERA decision).

Supporting document(s) for Justification/Discussion for Solution

ERA_Solution_proposal_for_CR1107_230315.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

NSA (Network of National Safety Authorities)

Contact person name J.R. VordereggerContact Person e-mail adress jochen.vorderegger@ivw.nlEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number IENM/IVW-2011/11222List of assigned WG(s)Severity Performances impact, non interoperability and non safety relatedTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassification

There is no demonstrated gap/inconsistency in the SRS and DMI v3.2.0 specifications

Reason for rejectionReason for postponement ERA CG 10/11/11: in the absence of unanimous support by the

sector for this CR, it is not taken into account for baseline 3 Superseding CRList of superseded CRs Date of Submission 2011-10-26 05:07:22 PMLast modification date 2016-01-06 04:10:54 PM

Identification number 1117State Presented_to_ECHeadline Reception of an order to terminate a communication session while

session is being establishedImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-026 v3.3.0, §3.5.5.7 Error/Enhancement ErrorProblem/Need description 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.

Supporting document(s) for problem/need descriptionSolution Proposal by submitterSupporting document(s) for solution proposalAgreed Solution Modify SUBSET-026 v3.4.0 as described in the attachment

"Solution_for_CR1117_161215.docx"Supporting document(s) for agreed solution

Solution_for_CR1117_161215.docx

Justification/Discussion for Solution

UNISIG 23/09/14See attachement «solution proposal for CR1117_20140923.docx» for a solution proposal.

ERA 01/10/14This solution proposal intends to fill the (tiny) gap of one of the “termination session” events occurring after the safe radio connection is set up and between the emission of the message “initiation of comm. Session” and the reception of the message “system version”. For that purpose the same bullet list as in 3.5.3.7 a) is re-used substituting the first bullet with “the driver closes the desk during SoM”.However, it is a fact that the setting up of the safe radio connection is part of the process to establish a session (it is the first step as specified in 3.5.3.7 a)) and from this it results that: - This proposed new clause 3.5.5.7 clearly overlaps with the bullet list in 3.5.3.7 a) - Item a) of the proposed list also causes the (max. 3) attempts to set up the safe radio connection to stop.Moreover, the existing clause 3.5.5.7 (especially extended as proposed) is not really covering the Termination of communication session itself and should not have been inserted in this section 3.5.5 (as a result of CR665).It is therefore proposed to move the proposed clause (slightly refined) into section 3.5.3 and to delete the bullet list of 3.5.3.7 a), in order to keep one single list of events that address at once all the situations (i.e. either during the setting up of the safe radio connection or during the exchange of applicative messages).

See attachment “solution proposal for CR1117_20140923_ERArev.docx” for details.

EUG 03/10/14We are not sure if the benefit of this CR is enough to justify the change of the specifications. We would need further clarification on whether this issue is coming from the experience of a project or from analysis on the paper.

EECT 08/10/14It is agreed to retain the ERA counter proposal posted on 01/10/14, but as requested by UNISIG without the add-on to the first sentence in 3.5.3.7 a). See "Solution_for_CR1117_081014.docx" for details.

EECT 03/11/15The Test Spec WG has spotted a flaw in the solution. They made a reading of the clause 3.5.3.7 a) as not having any exception and being contradicted by 3.5.3.9.1. Actually, the last minute withdrawal (on request by UNISIG) of the introductory sentence proposed by ERA has led to this misunderstanding.

ERA 26/11/15See part highlighted in blue in attachment "Solution_proposal_for_CR1117_261115.docx" for an updated solution proposal.

UNISIG 04/12/15See attached file "Solution_proposal_for_CR1117_261115-U.docx" for U comments on updated solution proposal posted by ERA on 26/11/15.

EECT 08/12/15The two comments made by UNISIG (04/12/15) are discussed, see replies tagged "EECT081215" in the Word comments inside the attachment "Solution_proposal_for_CR1117_EECT081215.docx".In addition the following editorial findings are detected: - in 3.5.5.7, a “.” should be added after “deleted” - in 3.5.3.7 a), a “.” should be added after "successful"

ERA 12/12/15As a result from the move of clause 3.5.3.8 to 3.5.3.7 d) the following modifications to the solution proposal are also necessary: - In the new clause 3.5.3.10, "3.5.3.7 d)" to be used instead of "3.5.3.8" - additional modification: In clause 3.17.3.7 replace “3.5.3.8” with “3.5.3.7 d)” - additional modification: In clause 4.4.6.1.13 replace “3.5.3.8 b)” with “3.5.3.7 d) 2nd bullet”

In addition, in the new clause 6.6.3.4.1.1 brought in by CR299, "3.5.3.7 d) 1st bullet" must be used instead of "3.5.3.8 a)".

See parts highlighted in blue in the attachment "Solution_for_CR1117_121215.docx" for the amendments resulting from the above and from the EECT meeting 08/12/15.

ERA 16/12/15Actually the re-use of the clause 3.5.3.8 is much better than the re-use of the clause 3.5.3.10 (deleted by CR1262) for the new clause brought in by this CR, for both readability reasons in the SRS final version without revision marks and in the SRS version with revision marks (no collision anymore with CR1262).See attachment "Solution_for_CR1117_161215.docx" in the field "Agreed Solution".

Supporting document(s) for Justification/Discussion for Solution

solution proposal for CR1117_20140923.docxsolution proposal for CR1117_20140923_ERArev.docxSolution_for_CR1117_081014.docxSolution_proposal_for_CR1117_261115.docxSolution_proposal_for_CR1117_261115-U.docxSolution_proposal_for_CR1117_EECT081215.docxSolution_for_CR1117_121215.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name L. RepettiContact Person e-mail adress luca.repetti@ansaldo-sts.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number 1117List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2013-12-20 05:27:33 PMLast modification date 2016-01-06 04:10:54 PM

Identification number 1122State Presented_to_ECHeadline Communication session establishment to report change to SL modeImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-026 v3.3.0 §3.5.3.4 c), 3.5.3.7 a), and 4.4.6.1.10 b)Error/Enhancement ErrorProblem/Need description 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 descriptionSolution Proposal by submitterSupporting document(s) for solution proposalAgreed Solution Modify SUBSET-026 v3.4.0 as follows:

Replace clause 5.5.2.2 with « Intentionally deleted »Delete clauses 5.5.2.2.1 and 5.5.2.2.1.1.

Supporting document(s) for agreed solutionJustification/Discussion for Solution

UNISIG 24/09/14The following modifications to Subset-026 are proposed: Replace 5.5.2.2 with « Intentionally deleted »Replace 5.5.2.2.1 with « Intentionally deleted »Replace 5.5.2.2.1.1 with « Intentionally deleted »

This proposed solution does not address the second part of the problem description ("Also, there is no restriction regarding the number of attempts...").We consider this issue as having to be solved.However, since this issue is wider than the case of the change of mode to/from SL mode (e.g. it also concerns the case of transition from PS mode to SB mode), we propose to solve it in a separate CR.

EUG 02/10/14The problem described by UNISIG comes from the CR 560, which included in section 4.5.2 the comment 1 (For ETCS level 2 and 3 this may imply establishing a radio communication session if none is established) and in the clause 3.5.3.4.c (If a mode change, not considered as an End of Mission, has to be reported to the RBC (only if level 2 or 3)). However we cannot trace back the reason to add “not considered as an End of Mission” in clause 3.5.3.4.c. Why not to clarify this clause 3.5.3.4 c)?

EECT 08/10/14Regarding the EUG question posted on 02/10/14: the mention “not considered as an End of Mission” in clause 3.5.3.4.c) was added on purpose, because it would not make any sense to require the on-board to open a session while the end of mission procedure includes the termination (ordered by the RBC) of an existing session.

The UNISIG solution proposal (24/09/14) is agreed as such.

EECT 08/12/15The sub-clauses of 5.5.2.2 shall be merely deleted without being marked "intentionally deleted".

Supporting document(s) for Justification/Discussion for SolutionPreliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name L. RepettiContact Person e-mail adress luca.repetti@ansaldo-sts.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number 1122List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2013-12-20 06:16:00 PMLast modification date 2016-01-06 04:10:54 PM

Identification number 1125State Presented_to_ECHeadline Clarification of human role in ETCS safety analysisImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-091 v320 §4.2.1.11Error/Enhancement ErrorProblem/Need description 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.

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 descriptionSolution Proposal by submitterSupporting document(s) for solution proposalAgreed 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 Subset-118, §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."

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 solutionJustification/Discussion for Solution

UNISIG 09/04/15The following modifications to Subset-091 v3.3.0 are proposed:- modify clause 4.2.1.11 to read:"The hazards and their associated THR relate to the failure to perfom 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 SRS, shall not be included in these hazards or their THR (see Subset-088 Part 3, §7.2.1.1 and Subset-118, §3.2.1.3 for details).b) When analyzing errors against which ETCS is designed to protect, the operator error may be 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 Onboard resulting in the display of incorrect information, the driver vigilance could be considered in THR calculation for this failure. If the driver vigilance and resulting actions are quantified in a safety analysis, it shall be done in a conservative way.Guidance on quantification can be obtained 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."

Note 1: this solution proposal offers the possibility to consider driver vigilance as mitigation of ETCS failures in THR calculations, which is in contradiction with point (3) of problem description. The reason for this is that driver vigilance is already used in other Subsets:- Subset-118 v1.2.6 „Functional Safety Analysis of ETCS DMI for ETCS Auxiliary Hazard“;- Subset-120 v0.2.11 „FFFIS TI – Safety Analysis“.When this CR was created we were maybe a bit too hard. After that two major safety analyses have been done within the scope of UNISIG: Subset-118 and Subset-120. What we learned then was that not crediting the driver in a manner according to points b) and c) of the above solution proposal would be too conservative and lead to unncessarily demanding safety requirements and thereby unjustified costs. Both subsets (Subset-118 and Subset-120) were already reviewed throughout the sector, so we consider this method of calculation with driver’s errors as agreed.

Note 2: in relation to Subset-088 v3.5.4 (B3 MR1) part 3, we have identified following confusion point, which will be clarified: in paragraph 7.2.1.1 of this subset, it is mentioned that the external hazardous events ENG, EXT and DRV do not contribute to the ETCS-THR. This is contradicting the fact that DRV-1 is included in the conceptual fault tree in Subset-088 part 1, and also against point b) of the solution proposal above.

EUG 14/04/15Our CR group does not have the competence to review in detail CRs on safety related documents such as Subset 91. Therefore we only have two small remarks: 1. It seems unbalanced to include mitigations by operators and drivers on ERTMS system faults (4.2.1.6 c) while to exclude mitigations of the ERTMS system on operators and drivers faults (4.2.1.6 a) or at least only allow it for a limited case (4.2.1.6 b). Is this CR solving a real issue or mainly a liability issue? 2. Why is subset-91 restricted to Level 1 and 2 when the specification (TSI CCS:ss26,..) and operational rules (TSI OPE) also cover Level 3?Aprat from these two small comments we trust that UNISIG has done a good job. If other issues are detected later on we will report them in the usual way (CCM process).

ERA 14/04/15In 4.2.1.11, UNISIG proposes to say that:“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 SRS, shall not be included in these hazards……the operator error may be quantified……the driver vigilance could be considered in THR calculation…. , it shall be done in a conservative way…”

This wording refers to the way a future safety analysis can/shall be performed; anyway, in chapter 4, it is explainied how the safety analysis that produced SUBSET-091 has been done and which principles have been applied. Also to be consistent with the rest of the chapter, the wording should be changed to “…have not been considered… have been quantified… has been considered…. has been done…."

EECT 15/04/15Regarding the two EUG remarks (14/04/15): 1) It is clarified that the proposed clause 4.2.6.1 a) does not say that there is no mitigations of the ERTMS system on operators and drivers faults. Actually it only refers to those operators and drivers faults not covered by ETCS functions, while as a matter of fact there are many ETCS functions covering operators and drivers faults (braking curves, roll away protection, etc…) 2) The extension of SUBSET-091 to level 3 is out of scope of this CR and its prerequisite is first to clarify what is a level 3 equipped train (e.g. can an on-board operate in level 3 without an train integrity device?) in the CCS WP and then after it is the resolution of both CR940 and 941.

UNISIG 05/05/15We agree that we erroneously used the future tense inside the rewording of §4.2.1.11 to describe activities that were already performed during the safety analyses. We also noticed that the last sentence needs to be reworded:- to highlight that the quantifications for the driver operational rules used in the analyses are already given in §10.4 and- to maintain a consistency with the title of the section.Moreover during the review of this CR we also noted that §10.4.1.8 needs to be reworded to be consistent with the scope of this CR. In fact in SUBSET 091 clause §10.4.1.8 states that:“These rules cover situations where, if a driver fails to obey information a hazardous situation could result. No assumptions about the vigilance of the driver acting in mitigation to ETCS failures have been made in the derivation of the safety targets.”But the rules described in §10.4.1.7 are not related to driver vigilance and, due to the introduction of SUBSET 118, driver vigilance has been taken into account in the Safety Analyses.

Update of proposed modifications to Subset-091 v3.3.0:- 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 Subset-118, §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." - 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 Justification/Discussion for SolutionPreliminary Assessment of Benefits

Supporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name L. RepettiContact Person e-mail adress luca.repetti@ansaldo-sts.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number 1125List of assigned WG(s)Severity Safety relatedTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2013-12-20 06:39:46 PMLast modification date 2016-01-06 04:10:55 PM

Identification number 1129State Presented_to_ECHeadline DMI indication of level announcement in SBImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References Subset 26-4 v3.3.0, 4.7.2 tableError/Enhancement ErrorProblem/Need description 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).

Supporting document(s) for problem/need descriptionSolution Proposal by submitterSupporting document(s) for solution proposalAgreed Solution 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.”

Supporting document(s) for agreed solutionJustification/Discussion for Solution

ERA 13/11/14The problem description is built on the assumption that for information which can give rise to driver’s indications a correspondence between the tables of accepted information (in SRS 4.8) and the table of DMI information depending on the mode (in

SRS 4.7.2) has to be sought.

This assumption is however in our opinion wrong. It is not because information is accepted in a given mode that a corresponding driver’s indication is triggered in that respective mode. There is consequently no demonstrated error in the current specification.

Moreover, displaying a level transition announcement in SB mode would breach the general ergonomic principle that information shall only be provided to the driver in due time when it is meaningful for running the train. As a matter of fact, in SB, indicating a level transition announcement is rather useless since the train cannot move yet. This will only become useful when leaving the SB mode.Considering the above reasons, the CR should be reclassified as enhancement and rejected.

UNISIG 21/11/14The rejection of this CR (i.e. the absence of level transition announcement in SB mode) will typically lead to the following effect: a train in SB mode that is within the acknowledgement window of an announced level transition will request the driver to acknowledge this level transition (see SRS 4.7.2, line “Ackn of level transition” in “Inputs” table). The driver will therefore see an acknowledgement request (which as such is an announcement of the level to be entered) popping-up on the DMI with no prior announcement of this level transition. Once the driver acknowledges, any level transition announcement information disappears from the DMI until the on-board executes the level transition.

If the absence of level transition announcement in SB in general and the behaviour described above in particular are OK for the operational experts, then the rejection of this CR is OK for UNISIG.

EUG 28-11-2014If we understand UNISIG well, the current specifications are already breaching the ergonomic principle stated by ERA in the last paragraph of 13/11. If the LTO is received in SB for current location, according to the input table of 4.7.2 the ack would be requested. This is fine because the driver just has to ack the level transition after it has taken place.But if the LTO is for further location and the onboard is already in the ack window, then the ack is requested and according to ERA this would breach the ergonomic principle. We agree with ERA on this principle. But the consequence would be that we have to differentiate the A in 4.7.2 input table. The condition for the ack to appear should be the immediate LTO.

EECT 03/12/14It is agreed that requesting an ack of a level transition located at a further location (i.e. the train is still inside the ack window) is inappropriate in SB. Therefore, the CR shall not be rejected and the row in table 4.7.2 (input information) should be split to discriminate the so called “post ack” from the ack inside the ack window (i.e. keeping only the A in SB for the so called “post ack”).

ERA 17/12/14

In table 4.5.2 (input information): - modify line "Ackn of level transition" to read "Ackn of level transition (after the level transition execution)" - add new line "Ackn of level transition (before the level transition execution)" with "A" for modes FS,LS,SR,OS,UN,TR,SN and with "NA" for modes SF,IS

EUG 19-12-2014Agreed with the assumption that "table 4.5.2" is a typo and should be "table 4.7.2".

EECT 13/01/15UNISIG wonders how this split of the line “ack of level transition” can be interpreted when the driver has not acknowledged within the ack window and the execution of the level transition takes place. Will the FIFO enter into play, because the two lines could be seen as referring to two separate objects? If yes the ack could be displayed twice with one second in between. Furthermore they wonder which would be the start/stop conditions for each ack.ERA replies that the stop condition for the display of any acknowledgment request is the driver’s ack itself and need not to be explicitly specified. For the start condition of the ack of level transition, they are specified by the clauses 5.10.4.1 a) and b).Actually, what should be made clear is that on passing a level transition only one of the two lines proposed in table 4.7.2 will be applicable during the whole process, i.e. the two lines are fully exclusive. ERA to provide an enhanced solution proposal to make clear that on passing a given level transition, only one ack request is displayed until the driver ack, regardless when it first appears (i.e. before or after the execution of the level transition).

ERA 04/02/15As per EECT 13/01/15, see updated solution proposal here below:In table 4.7.2 (input information): - modify line "Ackn of level transition" to read "Ackn of level transition (in case only a level transition order executed immediately by the on-board has been received)" - add new line "Ackn of level transition" to read "Ackn of level transition (in case a level transition order not executed immediately by the on-board has been received)" with "A" for modes FS,LS,SR,OS,UN,TR,SN and with "NA" for modes SF,IS

EECT 11/02/15According to UNISIG, the updated solution proposal posted by ERA on 04/02/15 does not cover the following scenario: 1. Onboard in SB receives LTO that is 1m in advance of the estimated position of the train – the condition for LTO ‘executed immediately’ is not fulfilled, so no request for ack will be displayed. 2. The Train rolls forward and the estimated position passes the border. The level changes. The condition for LTO ‘not executed immediately’ is fulfilled, but this row is not applicable to SB mode. Therefore, the level could change in SB without any request for driver acknowledgement. Although such occurrences might be rare, UNISIG does not think this onboard behaviour would be acceptable.

To cover this case, it is agreed to give up the split of the line “ackn of level transition” in table 4.7.2 and to adopt the following solution: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.”

Supporting document(s) for Justification/Discussion for SolutionPreliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name L. RepettiContact Person e-mail adress luca.repetti@ansaldo-sts.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number 1129List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2013-12-18 07:59:34 PMLast modification date 2016-01-06 04:10:55 PM

Identification number 1152State Presented_to_ECHeadline Avoid increase of permitted speed and target distanceImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-026 v3.3.0 §3.13.10.4Error/Enhancement ErrorProblem/Need description The SRS §3.13.10.4.2.1 and §3.13.10.4.7.1 avoids increase of

permitted speed and target distance due to SB feedback function.

When the train brakes, the following also happens:- Measured train speed decreases, - Measured brake pipe pressure decreases.

All these factors contribute to the increase of the displayed Permitted speed and target distance so it is difficult to say that this increase is really due to SB feedback

influence.Furthermore, it is unclear if the "real" Permitted speed and the "real" target distance have to be displayed again once the reduction of T_bs1 and T_bs2 ends (this could lead to a jump at that moment).

It has also to be noted that there are other situations that may lead to an increase of permitted speed and target distance: apart from a target change, it could also occur due to relocation or due to the driver being braking (the estimated train acceleration/deceleration values changes, the estimated train speed value changes in the equations).

Is the increase of the permitted speed and target distance in these situations OK from an operational point of view?

Supporting document(s) for problem/need descriptionSolution Proposal by submitter If these permitted speed and target increases are not OK from an

operational point of view, the “never increase” principle for the permitted speed and target distance could become general, i.e. no more restricted to the case of the SB feedback.

Supporting document(s) for solution proposalAgreed Solution Modify SUBSET-026 v3.4.0 as described in the attachment

"Solution_for_CR1152_141215.docx"Supporting document(s) for agreed solution

Solution_for_CR1152_141215.docx

Justification/Discussion for Solution

ERA 24/02/15As proposed by the submitter, the "never increase" principle currently specified for the SB feedback case only is generalised, for the speed and distance displays. The modifications to the SRS read as follows: Replace 3.13.10.4.2.1 and 3.13.10.4.7.1 with "Intentionally deleted".Add new clause 3.13.10.4.8.1 to read:"As long as there is no change of displayed target, the on-board equipment shall ensure that the displayed Permitted speed, the displayed SBI speed (if any) and the distance to target never increase (e.g. due to the progressive reduction of T_bs1 and T_bs2 when the service brake feedback functionality is active or e.g. due to relocation). In other terms if a concerned displayed value (VP_DMI, VSBI_DMI or target distance) calculated as above has a higher value than the previously displayed value, then the previous value shall remain displayed until a further calculated value is lower than the displayed one."

UNISIG 27/02/15When engineering a trackside it is common for balise groups to be placed on the approach to speed restrictions to minimise odometry error. A similar thing may be done to improve the approach to the EOA. The solution proposal posted by ERA on 24/02/15 would mean that the relocation would not result in a higher permitted speed being displayed, nor would it increase the distance to target displayed to the driver. Is this OK from an operational point of view?

Could it mean that the driver would continue to brake instead of coasting or even reaccelerating?

With regards to the ergonomics, when passing the BG the displayed permitted speed and distance to target will remain fixed at the same value until the max safe front end once again reaches the same location it was at before the relocation was performed. So, although it will be obvious to the driver that the train is approaching the target (i.e. the train is moving), the distance to target on the DMI will not decrease for a period of time (the duration will depend on the size of the confidence interval before the relocation and the speed of the train). From an ergonomics point of view, is this better than seeing a step increase of the permitted speed / target distance, which would then immediately start to decrease as the train approaches the target?

We propose operational/ergonomics experts to give their opinion on these points.

EUG 03-03-2015We share the concerns of UNISIG specifically with respect to the distance. Applying the "never increase" principle to the distance could mean that the driver will never be able to approach the EOA, or he would be forced already too early to the release speed. For the restriction of the speed we do not see such a problem.We would therefore propose the following.Deleting 3.13.10.4.2.1 and 3.13.10.4.7.1 is agreed.The proposal for 3.13.10.4.8.1 should refer only to speed, not to distance.

EECT 09/03/15Regarding the UNISIG comments 27/02/15, ERA observes that they somehow invalidate the problem description.EUG explains that they do not agree with the "never increase" principle for the target distance. In spite of the other EUG comment (“For the restriction of the speed we do not see such a problem”), ERA explains that there might be a strange effect because while the displayed speed is clipped the supervised speed is not. In case the displayed P speed plateau is long (e.g. further to a long distance without relocation it can last several hundreds of meters) and the driver would drive above this displayed P speed with no effect on the DMI (i.e. without any change to the supervision status), this could undermine his confidence in the system.Since the problem spotted by the submitter about the SB feedback functionality remains (the implementation and the testing of the clause 3.13.10.4.2.1 is impossible), it is wondered how the SB feedback functionality should really work, especially when there is relocation after the feedback algorithm has started to reduce Tbs1 and Tbs2 Considering the above, it is proposed to investigate whether the two clauses 3.13.10.4.2.1 & 3.13.10.4.7.1 could be just deleted (i.e. not replaced with another one generalising the principle).

EUG 08/04/15The following arguments are provided to keep the functionality for temporarily locking the displayed permitted speed and target

distance at SB feedback:1. TRV has implemented the functionality from EEIG 97E881 v.7A in our B2 onboard systems, and we are satisfied with this functionality regarding the SB feedback. A relocation cannot destroy a locking from the SB feedback.2. TRV has also implemented similar indication for SB feedback functionality in their STMs, with good experience.3. In the first simulator tests of the braking curves in Munich there was SB feedback without locking of the displayed permitted speed and target distance, and the drivers complained a lot about the jumpy indications. Therefore we introduced the locking of the displayed values.4. Without the locking the risk increases that the driver releases the brakes, if he/she interprets the increased values as a new target at a further location. Therefore we still propose to extend the locking of the displayed permitted speed and target distance for all braking (not only SB feedback), but not for relocation. When braking the risk for overspeed is less, and if in overspeed when starting to brake the speed will soon decrease. At relocation it is important to display the new supervised target distance.

EECT 15/04/15The EUG arguments (08/04/15) to keep the locking of the displayed permitted speed and target distance, when the SB feedback is active and even in case of relocation, are acknowledged.It is also clarified that when the SB feedback is not active, EUG would like to keep the locking of the speed and distance indications, however excluding those occurring when relocation takes place.However ERA proposes to adopt a conservative approach, consisting in: - only removing the parts of the clauses 3.13.10.4.2.1 & 3.13.10.4.7.1 (“if it results from the progressive reduction of T_bs1 and T_bs2”) challenged by U because impossible to implement, and - not extending the never increase principle when the SB feedback is not active. This is justified by the absence of evidence of speed and distance fluctuations when the SB feedback is not active and when no relocation takes place, compared to the existing return of experience for SB feedback valued by EUG.In addition, on request by UNISIG, it will be checked whether the term “service brake feedback functionality is active” is unambiguous, i.e. it can only be correlated with the Boolean “Q_feedback_started” referred to in the SB feedback algorithm.Conclusion: ERA to resume the solution proposal according to the above.

ERA 05/05/15The revised solution proposal reads as follows:

Replace 3.13.10.4.2.1 and 3.13.10.4.7.1 with "Intentionally deleted".

Add new clause 3.13.10.4.8.1 to read:"As long as the service brake feedback functionality is active (see Appendix A3.10 for details), the on-board equipment shall ensure that the displayed Permitted speed, the displayed SBI speed (if any)

and the distance to target never increase (e.g. due to the progressive reduction of T_bs1 and T_bs2 or e.g. due to relocation). In other terms if a concerned displayed value (VP_DMI, VSBI_DMI or target distance) calculated as above has a higher value than the previously displayed value, then the previous value shall remain displayed until a further calculated value is lower than the displayed one."

In section A.3.10.4: - modify the definition of Q_feedback_started to read: "Q_feedback_active = a Boolean stating whether the feedback function is active, i.e. once it has started to reduce T_bs1 and T_bs2 until the target has been passed or the target speed monitoring has been left" - replace "Q_feedback_started" with Q_feedback_active" (4 other occurrences)

EUG 13/05/15The first point is that in the EUG CR WG meeting it was accepted to restrict the CR to the service brake feedback as proposed in the last EECT. In addition, see comments from the EUG (TRV) on the new ERA proposal in attachment "CR1152-TRV_proposal_for_ modification.docx"

ERA 02/06/15Although the rationale for the modifications highlighted in yellow in the attachment "CR1152-TRV_proposal_for_ modification.docx" is not crystal clear, the EUG proposal is understood as a successful attempt to refine the currently specified condition “if it results from the progressive reduction of T_bs1 and T_bs2”, which had been agreed to be deleted in a previous step of the CR1152 discussion.As a result, we have only one editorial remark against the EUG proposal 13/05/15: the condition “a new target is selected for display” should read “a new target is selected as MRDT”.

UNISIG 04/06/15See attachment "CR1152-TRV_proposal_for_ modification-SG.docx" for UNISIG comments on file "CR1152-TRV_proposal_for_ modification.docx" posted by EUG on 13/05/15.

EECT 10/06/15EUG tables a new proposal during the meeting (see attachment "CR1152-TRV_proposal_100615.docx") which includes the feedback from TRV on the UNISIG comments posted on 04/06/15. On the basis of this proposal, the ERA/UNISIG comments are discussed:

- The ERA editorial remark (02/06/15) about the condition “a new target is selected for display” is accepted.

- Regarding the UNISIG comments (04/06/15), it appears that most of them consider the functional requirement defined during the EECT 15/04/15 as unchanged i.e. to keep the locking of the displayed permitted speed and target distance, as long as the SB feedback is active and even in case of relocation. However it is

confirmed during the meeting that the EECT 15/04/15 agreement looks to be indeed successfully challenged by EUG (as assumed by ERA quote 02/06/15) and that this proposal aims at isolating the contribution of the service brake feedback from the other events leading to the speed/distance increase. This unfortunate misunderstanding is mainly due to the fact that the EUG proposal does not contain any explanation of the retained principles. UNISIG requests EUG to mention clearly the retained principles in a preamble. As a consequence of the above, it looks better to keep the term “locking” and not to use “capping”.

- The additional modification proposed by EUG to compare the T_bs1 values for setting Q_displaylocked to true is already agreed by ERA.

It is also identified that the condition “and the displayed permitted speed starts to decrease again” shall be further clarified by actually comparing the locked (and displayed) permitted speed with the permitted speed computed for display purposes (VpDMI) as per clause 3.13.10.4.3.

EUG 01-07-2015See attachment "CR1152-EUG 20150701" for the updated TRV proposal.

EECT 08/07/15The EUG updated proposal (01/07/15) proposal is reviewed.ERA recalls that its previous comment 02/06/15 about the condition “a new target is selected for display” that should read “a new target is selected as MRDT” has not been taken into account.The UNISIG comments received prior to the meeting are addressed, see tags EECT080715 inserted inside the Word comments in the attachment "CR 1152 - EECT080715.docx".

In addition there are two new open points to be resolved: - which solution shall be retained: individual locking of VP_DMI, VSBI_DMI and target distance or locking controlled by the calculated permitted speed only or unlocking once one of the calculated value becomes lower than the locked one or any other possibility. - how the various variables (T_bs1prev but also the Booleans) are initialized. Each time the SB feedback becomes active, at each entry into TSM, for each supervised target,...?

EUG 25-08-2015See updated solution proposal 'CR 1152 - EECT080715_TRV-2015-07-29' covering the two open points

ERA 31/08/15See attachment "CR1152-TRV_290715clean_ERArev.docx" for further comments. Note: for readability reasons, the solution proposal has been cleaned up in order to show only (with revision marks) the modifications with regards to SRS 3.4.0.

UNISIG 01/09/15 See file in the attached zip archive "CR1152 U2015-09-01" for the UNISIG comments to the proposal per entry EUG 25-08-2015.

EECT 08/09/15The ERA and UNISIG comments on the EUG updated solution proposal 25/08/15 are reviewed, see replies tagged “EECT080915” in the Word comments inside the attachment "CR1152-EECT080915.docx".

ERA 24/09/15See parts highlighted in blue in the attachment "Solution_proposal_for_CR1152_240915.docx", resulting from the review (08/09/15) of the ERA and UNISIG comments.

UNISIG 01/10/15See attachment "Solution_proposal_for_CR1152_240915-U.docx" for UNISIG comments on solution proposal posted by ERA on 24/09/15.

EUG 05-10-2015We propose the following modifications to the ERA solution proposal "Solution_proposal_for_CR1152_240915.docx".

A3.10.4 "... until the target has been passed or until ceiling speed monitoring is entered." This wording is consistent with 3.13.9.3.3.4 and A3.10.6.

A3.10.5 “even if the train speed comes below the target speed of the MRDT.” This should be valid even if the MRDT changes during active locking in TSM.

EECT 07/10/15The review comments from UNISIG (01/10/15) and the resulting EUG proposal (05/10/15) for the two leftovers spotted by UNISIG are discussed.It is agreed to close the CR with two minor modifications, see parts highlighted in blue in the attachment "Solution_proposal_for_CR1152_EECT071015.docx".

EECT 08/12/15In the new clause 3.13.10.4.8.1, "progressive" shall be deleted to be in line with 3.13.9.3.3.4 (removal of "progressively").See attachment "Solution_for_CR1152_141215.docx" in the field "Agreed Solution".

Supporting document(s) for Justification/Discussion for Solution

CR1152-TRV_proposal_for_ modification.docxCR1152-TRV_proposal_for_ modification-SG.docxCR1152-TRV_proposal_100615.docxCR1152-EUG 20150701.zipCR 1152 - EECT080715.docxCR 1152 - EECT080715_TRV-2015-07-29.docxCR1152-TRV_290715clean_ERArev.docxCR1152 U2015-09-01.zipCR1152-EECT080915.docxSolution_proposal_for_CR1152_240915.docxSolution_proposal_for_CR1152_240915-U.docxSolution_proposal_for_CR1152_EECT071015.docx

Preliminary Assessment of Benefits

Supporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name L. RepettiContact Person e-mail adress luca.repetti@ansaldo-sts.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number List of assigned WG(s)Severity Performances impact, non interoperability and non safety relatedTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2012-11-18 08:13:57 PMLast modification date 2016-01-06 04:10:55 PM

Identification number 1163State Presented_to_ECHeadline Train interface – Track conditions related outputs to be harmonizedImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References 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/Enhancement ErrorProblem/Need description 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 Subset-034 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?- 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

CR1163 - attachment to problem description.pdf

Solution Proposal by submitter A functional solution is proposed, mainly to fill the "to be harmonized" parts of Subset-034 v3.0.0: see attachment "CR1163 – proposed solution for S-034". A detailed solution will have to be devised at FFFIS level.

Supporting document(s) for solution proposal

CR1163 - proposed solution for S-034.pdf

Agreed Solution Modify SUBSET-023 v3.1.0, 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_141215.docx"

Supporting document(s) for agreed solution

CR1163_solution_141215.docx

Justification/Discussion for Solution

EUG 21-02-2013The solution proposal is too generic. It gives no added information compared to what is already specified in the SRS. The level of detail should however be similar to the other parameters on the TIU. They provide information on the characteristics of the interface, e.g. a two or three state input with a clear definition of the values.We can understand that it is difficult at the moment to define the right level of specification for the track conditions in the FIS. We may need some deeper discussion on FFFIS level, but then we need to come back to the FIS to fill the missing items.In addition we have the following editorial comments on your solution proposal:2.3.4.3 - This is not a requirement for the TIU and should therefore be a note. Same is valid for the equivalent clauses in the other functions.2.3.4.2 - Here you say ".. where the special brake has to be inhibited", while in 2.3.4.4.1 you say "... request that the special brake has to be inhibited". The word "has" suggests that it is an order. The second sentence is therefore an internal inconsistency. It is either a request or an order, but it cannot be both at the same time. Please improve the consistency.2.4.4 - You speak about the air-conditioning intake which has (not) to be closed, while SRS 3.12.1.3 does not mention the air-conditioning intake, but only mentions the air tightness. Please be consistent with SRS.2.4.7 - You say "power switch open", while SRS 3.12.1.3 says "power switch off". Please be consistent with SRS.

UNISIG 06/09/13We acknowledge that our previous solution proposal was not detailed enough. We therefore prepared, in collaboration with UNISIG Train Interface experts, a more elaborated solution that is

based on the following principles:- two variants have been created : -- the variant 1 is based on the principle that the ERTMS/ETCS onboard equipment sends the remaining distance to the start and end of the track conditon, together with the current train speed and other information relevant for the handling of the track condition, to the ERTMS/ETCS external function and this external function generates the appropriate commands at the vehicle level based on this information -- the variant 2 is based on the principle that the ERTMS/ETCS onboard equipment generates itself the commands to be performed at the vehicle level.This is following the solution principles being specified in the Train Interface FFFIS, principles that are based on Industry experience.- a new section 5.20 has been created in the SRS. By analogy to section 5.18 for the track conditions display, this new section contains all the actions to be performed by the ETCS onboard to generate to the external function the information related to the supervised track condition.- Our analysis has revealed that regarding the station platforms and change of allowed current consumption, the function cannot be realised as « postman » . We therefore introduced the storage of this information with requirements on the replacement of stored information by new received one. We also created Subset-040 related dimensioning rules.

Our solution proposal modifies the following specifications:- Subset-026: -- Modifications to chapter 3 : see revision marks in the attached files <CR1163_modifs to SUBSET-026-3 v330_part 1.pdf >, < CR1163_modifs to SUBSET-026-3 v330_part 2.pdf >, < CR1163_modifs to SUBSET-026-3 v330_part 3.pdf > and <CR1163_modifs to SUBSET-026-3 v330_part 4.pdf>. -- Modifications to chapter 5 : creation of a new section 5.20 (see attached file <CR1163_modifs to SUBSET-026-5 v330_new section 5.20.pdf>)- Subset-040 : see revision marks in the attached file <CR1163_modifs to SUBSET-040 v320.pdf>- Subset-034 : see revision marks in the attached file <CR1163 modifs to SUBSET-034 v330.pdf>The files listed above are attached in archive <CR1163_updated_solution_proposal_130906.zip>

EUG 26-09-2013The following comments were presented by EUG to UNISIG during the joint session on 25/09. Note that each comment is given once, while for some of them there are similar other occurrences in the document (copy/paste issues).SRS chapter 5.20:1) What is the use of the information for the train specified in 5.20.2.11.3? UNISIG explained that some trains need to be informed in advance about the commands that will follow. UNISIG will clarify this with a note, also in several similar occurrences in this chapter.2) In 5.20.2.9a there is a "the" too many. Same in 5.20.3.9a.3) The words "point" and "location" are both used extensively in chapter 5.20 while they mean the same. Please use consistent

wording.4) Clause 5.20.2.11.5 contains the words "or powerless section with main power switch to be switched off" while this section is about powerless section with pantograph to be lowered. UNISIG explains that this due to the fact that the different areas might be partially overlapping. UNISIG will clarify this. 5) In the "changing the traction system function" the variant 2 as defined in 5.20.4.6 will create operational problems because the order is given at the moment when point F is passed. Compare variant 1 where the information is given before point F so that the train system can anticipate the necessary actions before point F is reached. The variant 2 should work in a similar way. If not it would be useless. UNISIG understands the concern and will propose a solution, i.e. either delete variant 2 or improve it in an operationally acceptable way. 6) The railways asked for the reason to use min safe rear end to terminate the platform function in 5.20.7.7 while at first sight the min safe front end would be appropriate. After internal discussion on the following day the railways agree that the min safe rear end is the right criteria to end the function. No further action needed.7) Post meeting note: It seems that in 5.20.1.1 the word "function" is missing after "external".Subset-0348) Regarding clause 2.4.1.4.3 the railways ask for the reason of the excessive range (up to 655.35m/s) and why it is in m/s. The railways accept the pragmatic explanation given by UNISIG (there would be no advantage in modifying it). No further action needed.9) In 2.4.1.5.2 there is one "traction" too many.10) In 2.4.1.5.4 a maximum number of 16 identifiers (i.e. 4 bits) for different traction systems is specified. The question is whether this is sufficient for all situations, since the track-train variable to send the traction system to the train is a 10 bit variable (which would have to be translated by the ETCS onboard into the 4 bit range on the TIU). UNISIG remarks that a specific train can be fitted only with a limited number of traction systems and that therefore the maximum of 16 was considered sufficient by the rolling stock experts on industry side.The railways have considered this internally after the joint meeting. We have tried to get information from the rolling stock experts on railway side, but the single answer we got was: ask the (rolling stock) supplier. And since these suppliers were involved in defining the range of 16 that would make the circle round. We therefore accept the range of 16 identifiers.11) The use of the word "country" in 2.4.1.5.4 and 2.4.1.5.1 in relation to the 4 bit identifier is misleading because the same word is used already in the context of the 10 bit identifier for the traction system variable on the airgap. UNISIG to correct this inconsistency e.g. by removing the word "country".12) The sentence " as the variable L_TRAIN in chapter 7 of [1]" in 2.4.1.4.4 is missing in the similar clause 2.4.2.4.4. UNISIG will add it.13) In 2.4.2.4.5 the range for the length of the powerless section is given to the maximum value that can be received from trackside and with a resolution of 1m. The question is how the onboard would handle cm values received from trackside which do not directly fit in the resolution of 1m. Some kind of rounding seems to be necessary

and UNISIG will clarify in the document how this is done.14) The wording in 2.4.4.5.3 (air conditioning intake) is not consistent with 2.4.5.2 (flap). UNISIG explains that 2.4.4.5.3 is consistent with the SRS while in 2.4.5.2 (which is about STM orders) the wording of Subset-035. The general principle should be that subdocs like Subset-034 and Subset-035 should following the wording of the SRS, not of another subdoc if that one uses different wording. UNISIG to consider this principle.

UNISIG 16/10/13See attachment "CR1163 UNISIG replies 16102013.docx" for UNISIG replies to EUG comments of entry EUG 26-09-2013. The attachment also considers the decisions made in the ERA-EUG-SG joint session which took place on 09/10/2013. See attached archive "CR1163 updated proposal 16102013.zip" for updated parts of the solution proposal. EUG 24-10-2013Agreed

ERA 30/10/13See attachment "CR1163_review sheet_ERA_301013.doc" for our review comments on the archive "CR1163 updated proposal 16102013.zip".

UNISIG 02/09/14Based on the ERA comments on the previous solution proposal (see ERA entry dated 30/10/13), the Super Group has prepared a new solution proposal (see attachment "CR1163 solution proposal - 20140902.docx").

ERA 05/09/14We agree with the content of the UNISIG proposal dated 02/09/14. However, we think it is possible to reduce significantly the number of pages by removing unecessary repetitions. See attachment "CR1163 solution proposal - 20140902_revERA.docx" for the details.

EUG 05-09-2014We have only one question regarding the UNISIG proposal. It seems that the variant 2 has completely disappeared. When discussing the old proposal with the 2 variants in 2013 we understood that the intention was to keep the specifications generic on the level of the SRS, but not necessarily to delete the the whole variant 2. See also the last paragraph of comment number 3 in "CR1163_review sheet_ERA_301013". Can UNISIG clarify this? How do we interface ETCS now with "simple" trains which do not have the intelligence to manage the panto's?

EECT 09/09/14UNISIG agrees with the editorial simplification proposed by ERA (see attachment “CR1163 solution proposal - 20140902_revERA.docx)".Regarding EUG question about the variant 2: UNISIG explains that variant 2 has been removed because it can anyway not address all types of vehicles In addition the retained solution does not prevent to

build variant 2 if needed. Whether the function to transform the remaining distances into elementary commands is implemented inside the EVC or in any other device in the vehicle is a project specific matter.With this explanation, the solution proposal “CR1163 solution proposal - 20140902_revERA.docx” is also agreed by EUG.

EECT 08/10/14In the course of the discussion of another CR, it is detected that the impact on SUBSET-027 of this CR has been overlooked.

UNISIG 22/10/14See attachment "CR1163 - SG proposal for SS-027 - 20141022.docx" for a proposal of modifications to be performed in Subset-027.

EUG 23-10-2014Agreed.

EECT 04/11/14The solution agreed on 09/09/14, enhanced with the SG proposal (22/10/14) for SUBSET-027, is agreed (see attachment "CR1163_solution_041114.docx").

UNISIG 16/07/15We detected some issues in the solution agreed on 04/11/14.These issues are as follows: - The agreed solution adds a bullet o) in clause 3.7.3.1 for the station platforms. A similar bullet for the allowed current consumption is missing in the solution - The agreed solution does not address the nominal height of the platform above rail level and the position of the platform - Clause 5.20.8.6 added by the agreed solution erroneously refers to a powerless section instead of a station platform - New bullet o) added by the agreed solution in SRS clause 3.7.3.1 should be amended as follows “New track condition Station Platforms information …” to have a structure similar to the other bullets of this clause - Clauses 2.4.5.1 and 2.4.8.1 of Subset-034 should be modified like clause 2.4.3.1 is modified by the agreed solution, i.e. replace « This » with « The » at the beginning of these clauses - In figures 26 and 31 of the agreed solution the letter “C” to mark the point C is missing - Spaces before or after quotation marks should be removed in several clauses of the agreed solution.

See parts highlighted in blue in the attachment "CR1163_solution_041114-U.docx" for an updated solution proposal which addresses these issues.

EUG 01-09-2015Agreed.

ERA 02/09/15We only have one comment on the attachment "CR1163_solution_041114-U.docx". The rest of the modifications is

agreed:In the SRS clause 5.20.8.4 and in the S-034 clause 2.4.6.1 of the solution proposal, the wording "in reference to a forward movement of the active cab " is used instead of the current wording of SRS 7.5.1.126.2 (Q_PLATFORM) "relative to direction of authorised movement". This needs to be at least clearly justified.

EECT 08/09/15The ERA comment (02/09/15) is discussed. The term “forward movement of the active cab” has been proposed by UNISIG because more understandable by RS experts. Unfortunately this term does not exist in the SRS. A quick brainstorming shows that what is actually meant is just the train orientation, which is currently defined in the SRS in clause 3.6.1.5. In addition, it appears that the term train orientation, which is used also in the SUBSET-034, should have been listed as an entry in SUBSET-023.It is therefore agreed to use the term “train orientation” both for the SRS and SUBSET-034 proposed modifications and to include an entry on SUBSET-023 explaining the correct definition for train orientation (understandable also for the RS experts).

UNISIG 02/10/15The solution is updated further to three issues detected by the Test Spec WG: - 5.20.8.8, 5.20.8.9, 3.7.3.2: these requirements in the new section 5.20 refer to the requirement 3.7.3.2, but this requirement does not deal with the track condition "Station Platform". - 5.20.7.7, 3.7.3.2: The requirement 5.20.7.7 refers to the requirement 3.7.3.2, but this requirement does not deal with the track condition "change of allowed current consumption", nor do any of the requirements in section 3.7.3. The solution proposal indeed wrongly refers to 3.7.3.2 while there is no initial state to be resumed for this track condition and needs a further update - 5.20.7.2: In this requirement the track condition "change of traction system " is mentioned, but it should say "the allowed current consumption", since it belongs to the subsection "5.20.7 Changing the allowed current consumption".

See parts highlighted in blue in the attachment "CR1163_solution_021015.docx".

EECT 07/10/15UNISIG informs that it was impossible to agree a definition for the train orientation in SUBSET-023, in particular because the term “train orientation” in SUBSET-034 clause 2.5.1.4.5 forms a circular reference (the “train orientation” in 2.5.4.1.5 leads to the determination of the “virtual” active cab but the train orientation in ETCS results itself from the active cab information received through the TI).Actually it appears that the SUBSET-034 clause 2.5.1.4.5 wrongly uses the term train orientation, with another meaning than the one used in the SRS. The real meaning is the “main running direction” of the vehicle, which can e.g. be determined through a dedicated switch.As a result, it is agreed: - to re-confirm the use of the term “train orientation” in the SRS

- in SUBSET-034 to replace “train orientation direction” with “main running direction” in 2.5.1.4.5 and to modify the note 2.5.1.4.6 to add “or a dedicated switch” at the end of the sentence. - to add an entry in SUBSET-023 for train orientation, with the content of the SRS clause 3.6.1.5.

ERA 15/10/15See parts highlighted in blue in the attachment "CR1163_solution_proposal_151015.docx" for the updated solution as per decisions taken in EECT 07/10/15.Note: in SUBSET-034, the term "train orientation" needs also to be fully eradicated from both clauses 2.5.1.4.5&6 and to be used in the new bullet of clause 2.4.6.1.

EECT 08/12/15The following amendments to the solution 15/10/15 are agreed:

- There is an inconsistent use of "platforms" and "platform" throughout the SRS => remove "s" in 3.7.3.1 o) (2 occurrences), 3.12.1.3 last bullet, 3.12.1.5 and chap 5 figure 31- The modification in 4.10.1.4.2 l) and m) has been forgotten => replace 4.10.1.4.2 l) and m) with "intentionally deleted"- The figures of section 5.20 contain trains with accompanying text boxes while the equivalent figures in 5.18 do not contain any => to be withdrawn- In 5.20.2.6 figure 25 is partly covered by a deleted figure 1 information- In 3.7.3.2 e) “station platform” is written without capital letter while it is the case two clauses above = > use "Station Platform”- The “initial state: not enabled” is not consistent with the functional ETCS use of the station platforms track condition => Replace “(initial state: not enabled) “ with “(initial state: no platform, i.e. passenger doors not enabled)”.- The first word of all the notes throughout section 5.20 should be capitalized.

See parts highlighted in blue in the attachment "CR1163_solution_141215.docx" in the field "Agreed Solution"

Supporting document(s) for Justification/Discussion for Solution

CR1163_updated_solution_proposal_130906.zipCR1163 UNISIG replies 16102013.docxCR1163 updated proposal 16102013.zipCR1163_review sheet_ERA_301013.docCR1163 solution proposal - 20140902.docxCR1163 solution proposal - 20140902_revERA.docxCR1163 - SG proposal for SS-027 - 20141022.docxCR1163_solution_041114.docxCR1163_solution_041114-U.docxCR1163_solution_021015.docxCR1163_solution_proposal_151015.docx

Preliminary Assessment of BenefitsSupporting document(s) for

preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name L. RepettiContact Person e-mail adress luca.repetti@ansaldo-sts.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number 1163List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2012-12-20 01:24:28 PMLast modification date 2016-01-06 04:10:55 PM

Identification number 1164State Presented_to_ECHeadline Ambiguity in assignment of coordinate systemImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-026, v3.3.0, §3.4.2.3.3Error/Enhancement ErrorProblem/Need description 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".

Supporting document(s) for problem/need description

CR1164 attachment to problem description.pdf

Solution Proposal by submitterSupporting document(s) for solution proposalAgreed Solution Modify SUBSET-026 v3.4.0 as described in the attachment

"ERA_solution_for_CR1164_130527.docx"Supporting document(s) for agreed solution

ERA_solution_for_CR1164_130527.docx

Justification/Discussion for Solution

ERA 27/05/2013No interoperability issue can be evidenced in the problem description which does not even quote an inconsistency/gap in any of the SRS requirements of section 3.4.2.3.3. It reveals a clear defect in the RBC which has most probably been designed mainly based on the description of a single variable (namely Q_ORIENTATION) rather than on a careful reading of all the requirements of section 3.4.2.3.3. The UNISIG analysis itself just

confirms the specification since it concludes that: “the only direction reference (shared between the onboard and RBC) that can be used unambiguously is the direction reference which is established and reported by the onboard in the position report based on 2 balise groups, as defined in 3.4.2.3.3.2 of the SRS”. Nevertheless, in the light of improving the editorial quality of the SRS, the modifications in attachment “ERA_solution_proposal_for_CR1164_130527” are proposed.

UNISIG 29/08/14The ERA solution proposal posted on 27/05/2013 is agreed.

EUG 29-08-2014This CR does not correspond to an error in the specifications since the clarification that is added can be directly derived from reading the complete clauses in the SRS. However, in order to improve the wording of specific clauses, the editorial improvement is accepted.Any development which has misinterpreted this specific clause is considered to have a product error since it would not be compliant to the rest of the clauses in the specifications.

Supporting document(s) for Justification/Discussion for Solution

ERA_solution_proposal_for_CR1164_130527.doc

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name L. RepettiContact Person e-mail adress luca.repetti@ansaldo-sts.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number 1164List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2013-01-24 04:33:09 PMLast modification date 2016-01-06 04:10:56 PM

Identification number 1167State Presented_to_ECHeadline Juridical data for the equivalent brake build-up timeImpacted System ETCS

Reference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References Subset 026 clause A3.9.4 and A3.9.6.

Subset 027 v3.0.0 section 4.2.4.2Error/Enhancement ErrorProblem/Need description 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)”).

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 descriptionSolution Proposal by submitterSupporting document(s) for solution proposalAgreed Solution Modify SUBSET-027 v3.1.0 as described in the attachment

"ERA_solution_for_CR1167_180914.docx"Supporting document(s) for agreed solution

ERA_solution_for_CR1167_180914.docx

Justification/Discussion for Solution

ERA 19/09/14See solution proposal in attachment "ERA_solution_proposal_for_CR1167_180914.docx"

UNISIG 24/09/14Solution proposal posted by ERA on 19/09/14 is agreed.

EUG 02/10/14Both the problem description and the solution proposal are focusing on capturing the two separate values for T_BRAKE_SERVICE(k) in the juridical recorder. If I understand it correct, then it is not considered that the value T_BRAKE_SERVICE could be dynamic due to the SB feedback function (if available). Is this aspect considered?

EECT 08/10/14Regarding the EUG comment 02/10/14: The CR is about a variable included in the message 2 “Train Data”, which de facto contains only static data, captured at SoM. The output from the feedback algorithm has not to be sent to the Onboard Recording Device (regardless of this CR) because what matters is to record the inputs (e.g. brake pressure) which go into this algorithm implemented in a SIL4 consituent.With this clarification, the ERA proposal 19/09/14 is agreed.

Supporting document(s) for Justification/Discussion for Solution

ERA_solution_proposal_for_CR1167_180914.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name L. RepettiContact Person e-mail adress luca.repetti@ansaldo-sts.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number 1167List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2013-12-18 08:24:57 PMLast modification date 2016-01-06 04:10:57 PM

Identification number 1169State Presented_to_ECHeadline Ambiguity about the variable L_STMPACKET in juridical data STM

INFORMATIONImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET 027 v3.0.0, SUBSET 058 v3.0.0Error/Enhancement ErrorProblem/Need description 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 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 descriptionSolution Proposal by submitterSupporting document(s) for solution proposalAgreed Solution Modify SUBSET-027 v3.1.0 as described in the attachment

"ERA_solution_for_CR1169_190914.docx"Supporting document(s) for agreed solution

ERA_solution_for_CR1169_190914.docx

Justification/Discussion for Solution

ERA 19/09/14See solution proposal in attachment "ERA_solution_proposal_for_CR1169_190914.docx"

UNISIG 24/09/14Solution proposal posted by ERA on 19/09/14 is agreed.

EUG 02/10/14Solution proposal posted by ERA on 19/09/14 is agreed.

Supporting document(s) for Justification/Discussion for Solution

ERA_solution_proposal_for_CR1169_190914.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name L. RepettiContact Person e-mail adress luca.repetti@ansaldo-sts.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number 1169List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement

reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2013-12-18 08:28:48 PMLast modification date 2016-01-06 04:10:57 PM

Identification number 1172State Presented_to_ECHeadline Problems related to level crossing supervisionImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET 026 v3.3.0Error/Enhancement ErrorProblem/Need description 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 non-protected 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 non-protected 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 on-board 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 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

CR1172_Attachment_problem_description.pdf

Solution Proposal by submitterSupporting document(s) for solution proposalAgreed Solution Modify SUBSET-026 v3.4.0 as described in the attachment

"ERA_solution_for_CR1172_141215.docx"Supporting document(s) for agreed solution

ERA_solution_for_CR1172_141215.docx

Justification/Discussion for Solution

ERA 19/09/14See solution proposal in attachment "ERA_solution_proposal_for_CR1172_180914.docx"

UNISIG 24/09/14See attachment "Unisig_SG_COM_CR1172_1.0.doc" for Super Group comment on ERA solution proposal posted on 19/09/14.

EUG 02/10/14Solution proposal posted by ERA on 18/09/14 is agreed.

EECT 08/10/14The UNISIG remark posted on 24/09/14 is accepted.See attachment "ERA_solution_for_CR1172_081014.docx" for details.

EECT 08/12/15The new bullet in A.3.5.1 shall read "as the EOA/SvL" instead of "as EOA/SvL" to be in line with the wording of 5.16.2 & 5.16.3.

See attachment "ERA_solution_for_CR1172_141215.docx" in the field "Agreed Solution".

Supporting document(s) for Justification/Discussion for Solution

ERA_solution_proposal_for_CR1172_180914.docxUnisig_SG_COM_CR1172_1.0.docERA_solution_for_CR1172_081014.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name L. RepettiContact Person e-mail adress luca.repetti@ansaldo-sts.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number 1172List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2013-12-18 08:44:18 PMLast modification date 2016-01-06 04:10:58 PM

Identification number 1180State Presented_to_ECHeadline Guard rails and cables in the vicinity of balisesImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-036 v3.0.0, § 5.7.10.4.1, 5.7.10.7.2, 6.6.10Error/Enhancement ErrorProblem/Need description 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 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.

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.

Supporting document(s) for problem/need description

Railcorp requests.pdfReply to query on guard rails and cables.pdf

Solution Proposal by submitterSupporting document(s) for solution proposalAgreed 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 solutionJustification/Discussion for Solution

UNISIG 17/10/14The following modifications to Subset-036 are proposed:- Regarding item 1 of the problem description, add at the end of section 5.7.10.4.1 the following text: "The meaning with gaps above is that it is either free air, or filled with dielectric material".

- Regarding item 2 of the problem description, add at the end of section 5.7.10.7.2 the following text:" 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. "

EUG 23-10-2014We are not experts on the details of the Subset-036 and therefore not qualified to give an expert opinion. We see however nothing wrong with the solution proposal, which is therefore accepted.

EECT 05/11/14According to ERA it is still not clear that for cables in the vicinity of the balise the exclusion zone does not apply to the cable connected to the balise. ERA wonders, since the distances defining the exclusion zone must respect at least the metal free volume as mentioned in clause 5.7.10.1 1st §, if such connection cable is to be understood as being part of the mentioned exception “mounting details”. UNISIG clarifies that it was not the original intention of this exception however it is obvious that in the case of 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” means that the distances A, B, C (which define the exclusion zone for cables) for the interface “C” cable are de facto equal to zero and that in all circumstances the maximum values for the induced currents must be respected.With this explanation, the UNISIG solution proposal 17/10/14 is agreed.

Supporting document(s) for Justification/Discussion for SolutionPreliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

ERA (European Railway Agency)

Contact person name A. HougardyContact Person e-mail adress alain.hougardy@era.europa.euEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number List of assigned WG(s)Severity Interoperability and non safety relatedTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2013-03-25 04:41:12 PMLast modification date 2016-01-06 04:10:58 PM

Identification number 1184State Presented_to_ECHeadline Missing requirement for the number of communication sessions an

OBU must be capable to handle simultaneouslyImpacted System ETCS&GSM-RReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-026 v3.3.0, § 3.15.1Error/Enhancement ErrorProblem/Need description The RBC/RBC handover procedure has been designed assuming

that the ETCS on-board equipment can handle two radio communication sessions simultaneously.In addition, the SRS clause 3.15.1.1.3 indicates that an RBC/RBC handover performed by a train with one communication session available may result in performance penalties.

However, in the absence of any mandatory requirement in any TSI CCS annex A document for the on-board equipment to be able to handle two communication sessions simultaneously, an on-board equipment fitted with two MTs (for redundancy purpose only) but without this functionality implemented in the ETCS on-board equipment, would be compliant with the TSI CCS.

This has been already spotted by Switzerland, through an ad-hoc National Technial Rule to be complied with for any placing into into service in Switzerland (see attachment "Swiss_NTR20.pdf").

Therefore a mandatory requirement applicable to the ERTMS/ETCS on-board equipment is necessary, in order to avoid the issuance of similar NTRs all over Europe.

Supporting document(s) for problem/need description

Swiss_NTR20.pdf

Solution Proposal by submitter Modify SUBSET-026 v3.3.0 as follows:

Modify clause 3.15.1.1.1 to read: "It shall be possible for the ERTMS/ETCS on-board equipment to manage two communication sessions simultaneously."

Add new clause 3.15.1.1.1.1: "Note: In case only one Mobile Terminal is available (i.e. only one communication session can be handled at once), the train will however be able to pass from one RBC area to another automatically (without driver action)."

Supporting document(s) for solution proposalAgreed Solution Modify EIRENE FRS v7.4.0, EIRENE SRS v15.4.0 and SUBSET-

026 v3.4.0 as described in the attachment "ERA_solution_for_CR1184_141215.docx"

Supporting document(s) for agreed solution

ERA_solution_for_CR1184_141215.docx

Justification/Discussion for Solution

ERA 28/04/15See attachment "ERA_Solution_proposal_for_CR1184_280415.docx" for the detailed solution proposal, which also includes the necessary modifications to the EIRENE specifications.

UNISIG 05/05/15See attachment "ERA_Solution_proposal_for_CR1184_280415-SG.docx" for comments on ERA solution proposal posted on 28/04/15.

EUG 06-05-2015We share the UNISIG comments on the ERA proposal.

EECT 13/05/15The UNISIG comments (05/05/15) are reviewed, see attachment "ERA_Solution_proposal_for_CR1184_EECT130515.docx".Only the reply to the comment #3 is not agreed by UNISIG. However, the CR will be closed (ERA decision) with the amendments as per agreed comments, pending the review of the ERA GSM-R CCM WG for the EIRENE part.

ERA GSM-R CCM WG 12/06/15

For the EIRENE part of the attachment "ERA_Solution_proposal_for_CR1184_EECT130515.docx", the following is agreed, see attachment "ERA_Solution_proposal_for_CR1184_GSMR120615.docx":

EIRENE SRS clause 16.3.8 : one editorial modification; suggestion from UNISIG to change wording to “ETCS connections” is accepted. EIRENE SRS: clause 16.3.8.1 : it is agreed not to add the note as proposed by UNISIG

In addition (out of the scope of the ERA CCM), the UIC was requested by CER and EIM to add an informative note in chapter 16 of EIRENE SRS (after 16.3.8) including the reasons supporting the fact of requesting at least 1+1 Mobile Terminals in the EDOR (for availability and for seamless handover CS-PS). This will be discussed in the UIC groups.

ERA 17/06/15The attachment "ERA_Solution_proposal_for_CR1184_GSMR120615.docx" still contains a missed replacement of "session" with "connection" in the EIRENE SRS clause 16.3.8.

Regarding the need expressed by CER and EIM for a "(I)" note explaining the background of the new "(MI)" requirement 16.3.8: we take note that it will be handled outside ERA CCM, however it can already be observed that the availability is definitely NOT the rationale for this CR. The rationale is to prevent ETCS compliant trains to perform non seamless RBC-RBC handover as long as there will be CS RBCs and/or change of Radio Networks.

EECT 08/07/15With the missing replacement of “sessions” with “connections” in the EIRENE SRS clause 16.3.8 (see ERA quote 17/06/15), the closure of the CR is confirmed, however still without the UNISIG agreement for the sake of their rejected comment #3 (see EECT 13/05/15). See attachment "ERA_solution_for_CR1184_080715.docx" for details.

EECT 08/12/15The following amendments to the solution 08/07/15 are agreed:- numbering issue: 3.9.3.5.2 shall actually be 3.9.3.5.1.1. The next clause is also to be renumbered accordingly.- The changes in 3.15.1.1.2 would lead to the wording "the RBCs behaviour" in the last sentence. This sounds weird and shall be replaced with “the behaviour of the RBCs” to clearly stick to original meaning of the sentence- 3.15.1.3.2 the deletion of former item “b)” is to be shown- 3.15.1.3.2: Replace “one communication session only at a given time“ with “only one communication session at a given time- 5.15.2.2.4.2.1: The “the” at the beginning of this clause should have a capital letter.

See parts highlighted in blue in the attachment "ERA_solution_for_CR1184_141215.docx" in the field "Agreed Solution"

Supporting document(s) for ERA_Solution_proposal_for_CR1184_280415.docx

Justification/Discussion for Solution

ERA_Solution_proposal_for_CR1184_280415-SG.docxERA_Solution_proposal_for_CR1184_EECT130515.docxERA_Solution_proposal_for_CR1184_GSMR120615.docxERA_solution_for_CR1184_080715.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

ERA (European Railway Agency)

Contact person name A. HougardyContact Person e-mail adress alain.hougardy@era.europa.euEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number List of assigned WG(s)Severity Performances impact, non interoperability and non safety relatedTarget Baseline Release ETCS B3R2 & GSM-R B1Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2013-05-30 04:04:58 PMLast modification date 2016-01-06 04:13:18 PM

Identification number 1187State Presented_to_ECHeadline Indication marker inconsistencyImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References Subset-026 330

ERA_ERTMS_015560 v330Error/Enhancement ErrorProblem/Need description 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.

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 descriptionSolution Proposal by submitter See attachment "EEIG418_solution_proposal".Supporting document(s) for solution proposal

EEIG418_solution_proposal.docx

Agreed Solution Modify SUBSET-026 v3.4.0 and ERA_ERTMS_015560 v3.4.0 as described in the attachment "ERA_Solution_for_CR1187_141215.docx"

Supporting document(s) for agreed solution

ERA_Solution_for_CR1187_141215.docx

Justification/Discussion for Solution

ERA 04/02/15Regarding item 1:This item is a duplicate of CR1026. There is no implicit definition of TSM specifically in clause 8.3.8.3., it is well known that throughout the DMI specification, the PIM and TSM areas forms the TSM as defined in the SRS. This is illustrated in the DMI Figure 11 and clause 7.3.1.1. This unfortunate editorial issue should anyway be resolved in CR1026.

Regarding item 2:See detailed solution proposal in attachment "ERA_Solution_proposal_for_CR1187_040215.docx" ensuring that the area B and the planning info are kept synchronised in terms of

transfer of object (i.e. when the yellow horizontal bar must disappear from the planning area at the same time the CSG becomes yellow) for the whole range of estimated speed.

UNISIG 27/02/15See attachment "ERA_Solution_proposal_for_CR1187_040215_SG.docx" for SG comments on ERA solution proposal posted on 04/02/15.

EUG 03-03-2015We support both suggestions from UNISIG to improve the ERA solution proposal.

EECT 09/03/15Regarding the UNISIG comments posted on 27/02/15: - comment 1: ERA acknowledges it but indicates that it will be very likely affected by the solution to the CR1249 about the pre-indication - comment 2: accepted

ERA 01/04/15See attachment "ERA_Solution_proposal_for_CR1187_010415.docx" for the revised solution proposal, which must be considered in conjonction with the CR1249 solution proposal 01/04/15.Regarding the UNISIG comments posted on 27/02/15: - comment 1: In line with the CR1249 solution proposal 01/04/15, the indication marker is only shown in CSM, which means that the problem does not exist anymore. - comment 2: it is no longer relevant since this part of the formula is no longer needed because of CR1249

EECT 13/05/15The revised ERA solution proposal (01/04/15) is agreed by both EUG and UNISIG.

ERA 21/05/15The modification to the row "Indication location at MRSP speed (see 3.13.10.4.11)" in the SRS table 4.7.2 (output information) was overlooked, see attachment "ERA_Solution_for_CR1187_210515.docx" for the updated solution.

EECT 08/12/15In the DMI spec part, the former text “where the TSM of the current target starts” in 8.3.8.1 should appear as deleted.The spelling of Indication location should be identical in 3.15.10.1 and 4.7.2, i.e. with a capital ‘I’.See attachment "ERA_Solution_for_CR1187_141215.docx" in the field "Agreed Solution"

Supporting document(s) for Justification/Discussion for Solution

ERA_Solution_proposal_for_CR1187_040215.docxERA_Solution_proposal_for_CR1187_040215_SG.docxERA_Solution_proposal_for_CR1187_010415.docxERA_Solution_for_CR1187_210515.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment Benefits

Economic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

EEIG (ERTMS users group)

Contact person name R. DijkmanContact Person e-mail adress rdijkman@ertms.beEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number EEIG418List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs 1078

Date of Submission 2013-07-17 05:27:22 PMLast modification date 2016-01-06 04:10:59 PM

Identification number 1188State Presented_to_ECHeadline Balises in Multi-Rail TrackImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-036 v300Error/Enhancement ErrorProblem/Need description 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 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 descriptionSolution Proposal by submitter Include at the chapter 5.6 the following sentence:

‘In case of the multi-rail track, the requirements of this document are to be applied separately to each pair of rails designed to be operated as separate track’.

Supporting document(s) for solution proposalAgreed 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 solutionJustification/Discussion for Solution

UNISIG 24/10/14We propose to add at the end of section 5.6.2.3 of Subset-036 the following text:"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."

EECT 05/11/14The UNISIG proposal 24/10/14 is agreed.

Supporting document(s) for Justification/Discussion for SolutionPreliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

EEIG (ERTMS users group)

Contact person name R. DijkmanContact Person e-mail adress rdijkman@ertms.be

Endorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number EEIG421List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2013-08-01 02:09:44 PMLast modification date 2016-01-06 04:10:59 PM

Identification number 1190State Presented_to_ECHeadline UES text message end conditionImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-026 V330Error/Enhancement EnhancementProblem/Need description 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 "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 descriptionSolution Proposal by submitter Modify Subset-026 V330 as follows:

1) Copy the text of clause 4.4.13.1.3 to a new clause 4.4.14.1.x and add an "A" in table 4.7.2 row "trip reason", column PT. Note: This proposal is relevant for all trip reasons (not only for UES) and it needs to be confirmed by operational experts.2) Add 3.10.2.6.1 to say: "When receiving an unconditional emergency stop the information to the driver about the accepted emergency stop shall coincide with the information on the trip reason.Add 3.10.2.6.2 to say: "The common information emergency stop / trip reason shall disappear only when the following condition is met: (all emergency stops have been revoked) AND (mode has changed to a mode not being TR or PT mode)."

Supporting document(s) for solution proposalAgreed Solution Modify SUBSET-026 v3.4.0, ERA_ERTMS_015560 v3.4.0 as

described in the attachment "Solution_for_CR1190_091214.docx"Supporting document(s) for agreed solution

Solution_for_CR1190_091214.docx

Justification/Discussion for Solution

ERA 17/11/14 See attachment "ERA_solution_proposal_for_CR1190_181114.docx" for justification and detailed solution proposal.

EUG 26-11-2014In principle we agree the ERA proposal.It would be good to double check with operational experts if it is acceeptable from an operational point of view. E.g. the fact that a CES which will not lead to a trip will not be indicated to the driver and the fact that the revocation of an ES will not be visible in PT mode.

UNISIG 26/11/14

If removing the indication that at least one Emergency Stop has been accepted and is not yet revoked is OK for the operational experts, then the ERA solution proposal is OK for UNISIG.

EECT 03/12/14The CER/EIM experts of the ERA OH WG confirmed the ERA solution.The attachement "ERA_solution_proposal_for_CR1190_181114.docx" is consequently agreed.

Supporting document(s) for Justification/Discussion for Solution

ERA_solution_proposal_for_CR1190_181114.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

EEIG (ERTMS users group)

Contact person name R. DijkmanContact Person e-mail adress rdijkman@ertms.beEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number EEIG416List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassification

This CR does not demonstrate any gap/inconsistency in the specifications. It would only extend the existing functionality in order to help the driver coping with a sudden loss of memory under a stressful situation.

Reason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2013-07-17 05:21:26 PMLast modification date 2016-01-06 04:10:59 PM

Identification number 1197State Presented_to_ECHeadline Ambiguity regarding the temporary EOAs and SvLsImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision (EU) 2015/14)Documents and/or References SUBSET-026 v3.4.0

ERA_ERTMS_015560 v3.4.0Error/Enhancement ErrorProblem/Need description The wording of the following SRS clauses (modified on purpose by

CR601 and CR823) is intended to specify that there is only one EOA supervised at a time by the on-board, “the” EOA:

- Beginning of a mode profile: SRS v3.4.0 (SH: 5.7.3.4, OS: 5.9.3.5, LS: 5.19.3.5): "Until the ERTMS/ETCS on-board equipment has switched to XX mode......the beginning of the XX area shall be considered either as the EOA (keeping the SvL given by the MA) or as both the EOA and SvL…” - Route unsuitability: SRS v.3.4.0 (3.12.2.4): "If at least one unsuitability exists, the closest location corresponding to the unsuitability(ies) shall be considered as both the EOA and SvL (instead of the EOA and SvL given by the MA), with no Release Speed". - Unprotected level crossing: SRS v3.4.0 (5.16.1.1): "....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".

The clause 3.13.8.2.2 also supports that the beginning of the mode profile is "the" EoA:".......(e.g. new MA and/or track description accepted on-board, EOA and/or SvL temporarily supervised at the start location of a mode profile, update of stored information in specific situations (see sections A.3.4 and 4.10))".

However the following clauses make a distinction between the EoA and the beginning of the mode profile: - SRS 3.15.10.1: “…….if any (e.g. the EOA or the start location of a mode profile)…..” - ERA_ERTMS_015560 8.3.6.3: “The symbols shall follow all MRSP discontinuities (see Figure 78 and Figure 80), the EOA/LOA location and, if any, the start location of a mode profile….”. - ERA_ERTMS_015560 8.3.7.1.1: “Note: The PASP is based on the MRSP, on the EOA/LOA location and, if any, on the start location of a mode profile computed by the on-board…”

The three above mentioned clauses may therefore mislead an average reader of the specifications, about whether the clause 3.8.2.3 a) (MA request a defined time before the train reaches the pre-indication location for the EOA/LOA) also applies to the EOA related to temporary situations (mode profile start location, start location of a LX not protected, route unsuitability).This is in particular relevant when the RBC expects the on-board to send a MA request on the basis of the start location of a LX not protected information being supervised as "the" EOA, in order to trigger the LX closure itself.

Supporting document(s) for problem/need descriptionSolution Proposal by submitter Modify SUBSET-026 v3.4.0 as follows:

in clause 3.15.10.1, replace "the first target at zero speed, if any (e.g. the EOA or the start location of a mode profile)" with "the EOA/LOA"In clause 3.15.10.2, replace "the first target at zero speed" with "the EOA/LOA".In table 4.7.2 (output information), replace "First target at zero speed" with "EOA/LOA"

Modify ERA_ERTMS_015560 v3.4.0 as follows:In clause 8.3.6.3, replace ", the EOA/LOA location and, if any, the start location of a mode profile" with "and the EOA/LOA location"

In clause 8.3.7.1.1, replace ", on the EOA/LOA location and, if any, on the start location of a mode profile computed by the onboard" with "and on the EOA/LOA location"

Supporting document(s) for solution proposalAgreed Solution Modify SUBSET-026 v3.4.0 as follows:

in clause 3.15.10.1, replace "the first target at zero speed, if any (e.g. the EOA or the start location of a mode profile)" with "the EOA/LOA"In clause 3.15.10.2, replace "the first target at zero speed" with "the EOA/LOA".In table 4.7.2 (output information), replace "First target at zero speed" with "EOA/LOA"

Modify ERA_ERTMS_015560 v3.4.0 as follows:In clause 8.3.6.3, replace ", the EOA/LOA location and, if any, the start location of a mode profile" with "and the EOA/LOA location"In clause 8.3.7.1.1, replace ", on the EOA/LOA location and, if any, on the start location of a mode profile computed by the onboard" with "and on the EOA/LOA location"

Supporting document(s) for agreed solutionJustification/Discussion for Solution

EUG 06-07-2015In principle solution by submitter is OK. Just one small remark. The wording of the solution proposal is not 100% equivalent to the current wording. The LOA is added. Please clarify that it is still equivalent.

UNISIG 06/07/15Regarding solution proposal from ERA: see attachment "CR1197 solution proposal - U.docx" for UNISIG comments on this solution proposal.

EECT 08/07/15Regarding the EUG remark 06/07/15: ERA explains why the term LOA is added throughout the solution proposal. Actually with a strict reading of clauses 3.15.10.1&2, which only include the terms "the first target at zero speed" and MRSP, the LOA would not be shown on the planning info because the LOA is not part of the MRSP. ERA therefore confirms that the term “the first target at zero speed “ has been adequately replaced with “EOA/LOA”.With this clarification, EUG agrees with the ERA solution proposal.

Concerning the UNISIG paper “CR1197 solution proposal - U.docx”, ERA is also surprised that UNISIG never reacted during those last years in the frame of the braking model definition when the section 3.13.8.2 was introduced. It is crystal clear in this section that the list of supervised targets can contain only one and only one EOA (which can change from a location to another e.g. when supervising the entry of a mode profile, 3.13.8.2.2). With the UNISIG interpretation, this section would be drastically different having as many supervised targets as there are “temporary” EOA’s. Moreover, it is rather obvious from the definition of an EOA that the location that prevails in case of multiple EOA’s candidates is the closest one since EOA means end of authority... It is common sense that the closest one is the end of authority otherwise it would not be actually an “end”.

Concerning the list of clauses pointed by UNISIG, ERA does not see any of them problematic except the reference in table 4.5.2 to chapter 3.8 which is unfortunate. However ERA stresses that anyway none of these questions is related to the CR1197 but rather to the separate CR gathering the presumed drawbacks of having only one EOA/LOA supervised at a time. Therefore the content of the UNISIG paper “CR1197 solution proposal - U.docx” will be moved to the separate CR.Conclusion : the CR is closed with the solution proposal by the submitter (agreed by EUG) without UNISIG agreement.

Supporting document(s) for Justification/Discussion for Solution

CR1197 solution proposal - U.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

ERA (European Railway Agency)

Contact person name P. PrieelsContact Person e-mail adress philippe.prieels@transport.alstom.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2013-12-16 01:49:22 PMLast modification date 2016-01-06 04:10:59 PM

Identification number 1213State Presented_to_ECHeadline SUBSET-091 upgrade to Baseline 3 Release 2 (B3R2)Impacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision (EU) 2015/14)Documents and/or References SUBSET-091 v.3.4.0Error/Enhancement EnhancementProblem/Need description SUBSET-091 needs to be updated for the Release 2 of Baseline 3

by implementing the solutions of the agreed CRs impacting it. The related changes in the subset are marked CR 1125 (Clarification of human role in ETCS safety analysis) and CR 1265 (Miscellaneous

editorial findings in B3 MR1).

Update of the list of informative documents in section 3.1.1.3 is also necessary, in order to reference the versions that will be released for B3R2:SUBSET-079-1 v3.14.0SUBSET-079-2 v3.14.0SUBSET-080 v3.2.0SUBSET-081-1 v3.4.3SUBSET-081-2 v3.4.3SUBSET-088-1 Part 1 v3.6.0SUBSET-088-2 Part 1 v3.6.0SUBSET-088-1 Part 2 v3.6.0SUBSET-088-2 Part 2 v3.6.0SUBSET-088 Part 3 v3.6.0SUBSET-118 v1.3.0

In addition, the UNISIG RAMS WP analyzed all the CRs of the B3 Release 2 to determine if changes to SUBSET-091 were needed to have consistent safety documentation and concluded that changes were necessary because of CR 1229.This CR changed paragraph 5.3.1.3 of SUBSET-041 and this paragraph is referenced in the Annex A (KERNEL23) of SUBSET-091, hence the need for update.

Finally: it has to be noted that the starting point for this update is not the version 3.3.0 of SUBSET-091 referenced by the TSI CCS annex A modified by decision (EU) 2015/14, but its upgrade to version 3.4.0 that incorporates the correction described in the Agency opinion ERA/OPI/2014-8 (here attached for ease of reference). However, the UNISIG RAMS WP discovered the need of update of Annex A for consistency because in this annex is referenced ETCS Auxiliary Hazard in ETCS_OB10 which was modified by the Opinion. It is therefore proposed to include all DMI hazards of ETCS_OB10 in the table of Annex A.

Supporting document(s) for problem/need description

Opinion - ERA-OPI-2014-8.PDF

Solution Proposal by submitter See attachment "SUBSET-091 v3.4.1".Supporting document(s) for solution proposal

SUBSET-091 v3.4.1.docx

Agreed Solution Modify SUBSET-091 v3.4.0 as described in the attachment "SUBSET-091_v360_revmarks.docx"

Supporting document(s) for agreed solution

SUBSET-091_v360_revmarks.docx

Justification/Discussion for Solution

UNISIG 16/12/15In addition to the incorporation of CR1283, the following minor changes are also necessary in Annex A table: add few non-breakable spaces instead of normal spaces after some indefinite articles “a” and “an” to have them on the new line together with following word and not alone on the end of line.See attachment "SUBSET-091 v342.docx".

UNISIG 10/05/16The SUBSET-091 is further updated to version v3.5.2, mainly because of the impacts due to the CR1249 follow-up (the complement solution discussed in 2016). Because of that, the

functional safety analysis of ETCS DMI for ETCS Auxiliary Hazard, SUBSET-118, has been updated to version 1.2.10 and this has been reflected in SUBSET-091 as follows:

- clause 7.2.1.5 – in ETCS_OB10 table were added DMI-01h, DMI-01i, DMI-03g, DMI-03h- clause 12.1.1.3 – also added DMI-01h, DMI-01i, DMI-03g, DMI-03h

In addition, changes has been made to reflect the correct versions of the informative documents SUBSET-078 and SUBSET-081 that were used in the making of SUBSET-091, as follows:

- clause 3.1.1.3 – referenced version of SUBSET-078 changed from 3.3.2 to 3.4.0- clause 3.1.1.3 – referenced version of SUBSET-081 part 1 and 2 changed from 3.4.3 to 3.5.0- clause 12.1.1.3 – event TI-6a has been deleted. (Justification: In the updated version of SUBSET-080 v3.1.5, TI-6a “Loss of Cabin Active Signal” has severity RAM Issue, No transition to SL mode is possible under the external constrain that the vehicle has to ensure that sleeping input is received only if another cab in the train is active (i.e. another train control system, ETCS or national, provides the supervision of the train movement). As stated in clauses 5.4.1.4 and 7.1.1.6 of actual SUBSET-080.)

See attachment "SUBSET-091_v352_revmarks_to_340".

EECT 11/05/16In the absence of any time left for a further review, the only comment to the document delivered by UNISIG on 10/05/16 is to adapt the modification history labels to the other documents updated further to the CR1249 reopening (i.e. the version 3.6.0 of the document will correspond to the B3 R2 version and not anymore the version 3.5.0)

Supporting document(s) for Justification/Discussion for Solution

SUBSET-091 v342.docxSUBSET-091_v352_revmarks_to_340.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name P. PrieelsContact Person e-mail adress philippe.prieels@transport.alstom.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number 1213List of assigned WG(s)Severity Safety relatedTarget Baseline Release ETCS B3R2Reason for Error/Enhancement

reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2015-12-04 08:30:43 PMLast modification date 2016-05-13 02:41:48 PM

Identification number 1221State Presented_to_ECHeadline Availability of Override and Start buttonsImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-026 v3.3.0

ERA_ERTMS_015560 v3.3.0Error/Enhancement ErrorProblem/Need description 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 when:a) The train speed is under or equal to the speed limit for triggering the override function (national value) ANDb) 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) ANDc) 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 descriptionSolution Proposal by submitterSupporting document(s) for solution proposalAgreed Solution Modify SUBSET-026 v3.4.0, ERA_ERTMS_015560 v3.4.0 as

described in the attachment "Solution_for_CR1221_091214.docx"Supporting document(s) for agreed solution

Solution_for_CR1221_091214.docx

Justification/Discussion for Solution

ERA 17/11/14See attachment "ERA_solution_proposal_for_CR1221_171114.docx" for detailed analysis and solution proposal.

EUG 26-11-2014ERA proposal 17/11 agreed.

UNISIG 26/11/14ERA solution proposal posted on 17/11/14 is agreed.

Supporting document(s) for Justification/Discussion for Solution

ERA_solution_proposal_for_CR1221_171114.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name P. PrieelsContact Person e-mail adress philippe.prieels@transport.alstom.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number List of assigned WG(s)Severity Interoperability and non safety relatedTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejection

Reason for postponementSuperseding CRList of superseded CRs Date of Submission 2013-12-18 01:00:37 AMLast modification date 2016-01-06 04:11:00 PM

Identification number 1222State Presented_to_ECHeadline Inconsistency regarding list of BGs for SH areaImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-026 v3.3.0Error/Enhancement ErrorProblem/Need description 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.

Supporting document(s) for problem/need descriptionSolution Proposal by submitterSupporting document(s) for solution proposalAgreed Solution 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 solutionJustification/Discussion for Solution

ERA 14/08/14Regarding the presumed inconsistency between table 8.4.4.4.1 and section 8.7.5: this could be seen as a leftover of CR 919, which added intentionally the packet 49 as an optional packet to the message “Request to Shorten MA”. However the editorial inconsistency is primarily between section 8.7.5 and clause 8.4.4.6.1, which gives the section 8.4.4.4 as the reference for the optional packets of any concerned track-to-train message. This is why nowhere else than in section 8.7.5, the cell remark is filled next to the mention “Optional packets”.The second part of the problem/need description about A.3.4 is wrong, because A.3.4 is about accepted and stored information. This means this is a previously stored list of balises for SH area that is deleted according to table A.3.4 and that can be replaced with a new one which is included in a “Request to Shorten MA” message.

It is therefore proposed to 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"

EUG 29-08-2014This CR does not correspond to an error in the specifications since the clarification that is added can be directly derived from reading the complete clauses in the SRS. However, in order to improve the wording of specific clauses, the editorial improvement of ERA is accepted.Any development which has misinterpreted this specific clause is considered to have a product error since it would not be compliant to the rest of the clauses in the specifications.Because this CR is only an editorial improvement, it has by definition no consequences on compatibility, i.e. no compatibility assessment necessary

UNISIG 08/09/14First part of problem description: solution proposal is ok.

Second part of problem description: Whilst we agree that the intended onboard behaviour is as ERA describe, there is a problem about when the information in the message is “accepted and stored”. The evaluation of the cooperative shortening in accordance with SRS 3.8.6 is not part of the evaluation criteria defined in SRS 4.8. This means that the check defined in 3.8.6 can only apply in a further step once the cooperative shortening has passed the 4.8 filter (see A.3.3 which confirms this reading).

This leads to the following problem: the 4.8 filtering is applied simultaneously (and collectively) to the information in the received message, and the cooperative shortening and the list of balise groups are ‘Accepted’. The cooperative shortening is however subject to the further check defined in SRS 3.8.6. No such additional check is required for the List of BGs. So, if the List of BGs is considered to be “Accepted” as soon as passing the 4.8 filter, then this list could be deleted when the onboard grants the cooperative shortening request in a further step.

There is also a related problem in that the List of Balise Groups and Mode Profile sent in the Message 9 can be accepted in accordance with the 4.8 filter, but the cooperative shortening itself may then be rejected in a further step when evaluated in accordance with 3.8.6. This would lead to the onboard accepting a mode profile and list of balise groups that does not match the currently stored MA. This is perhaps an even bigger problem than described in the problem description.

EECT 09/09/14After a further evaluation, it is recognised that the second part of the CR problem description addresses an issue related to the Cooperative MA shortening, which is wider than expected. However the CR can be closed with only the item 1 agreed and without the item 2 that will be moved to another CR.

Supporting document(s) for Justification/Discussion for

SolutionPreliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name P. PrieelsContact Person e-mail adress philippe.prieels@transport.alstom.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2013-12-18 01:16:45 AMLast modification date 2016-01-06 04:11:00 PM

Identification number 1229State Presented_to_ECHeadline Age requirement for estimated speedImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References Subset-041 V310Error/Enhancement EnhancementProblem/Need description 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.

Supporting document(s) for problem/need descriptionSolution Proposal by submitter The intention of ProRail is not to impose a specific requirement. It

would be sufficient to define the performance of the existing products in the Subset-041. In that case there would be no impact on the products, but the railways could use the defined value in their

LX analysis.Supporting document(s) for solution proposalAgreed Solution 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 agreed solutionJustification/Discussion for Solution

ERA 26/05/15The necessary modifications to the SUBSET-041 v3.1.0 are the following: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"

EUG 02/06/15ERA solution proposal is agreed by EUG.

UNISIG 03/06/15ERA solution proposal posted on 26/05/15 is agreed.

Supporting document(s) for Justification/Discussion for SolutionPreliminary Assessment of Benefits

ProRail intends to use ERTMS position reports in level 2/3 as a trigger to activate the LX. This could greatly enhance to time during which the LX is closed, which is very beneficial for the flow of the road traffic and it avoids road traffic trying to pass the protected LX due to long closing time.To be able to use this ERTMS functionality with the required level of safety, the limit for the age of the speed value in the position report should be defined, just as it is today for the position value.

Supporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

EEIG (ERTMS users group)

Contact person name R. DijkmanContact Person e-mail adress rdijkman@ertms.beEndorsed by Recognised Organisation(s)Project Information Submitter Reference Number EEIG419List of assigned WG(s)Severity Performances impact, non interoperability and non safety relatedTarget Baseline Release ETCS B3R2

Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2014-01-09 12:26:48 PMLast modification date 2016-01-06 04:11:00 PM

Identification number 1236State Presented_to_ECHeadline Criteria for Levels in train unclearImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References Subset-026 V330Error/Enhancement ErrorProblem/Need description 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”.

Supporting document(s) for problem/need descriptionSolution Proposal by submitter 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”.Supporting document(s) for solution proposalAgreed Solution 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 solutionJustification/Discussion for Solution

ERA 27/10/14Unlike what is claimed by the submitter, the concept of "level x equipped train" is existing in the TSI CCS. It is above all a concept which is out of the scope of the SRS (which only specifies the functionality of the ERTMS/ETCS system) and in addition the incriminated SRS clause 2.6.2.5 is redundant with the provisions of the TSI CCS clause 2.3.Therefore it is proposed to simply replace both the clause 2.6.2.5 and 2.6.2.6 with “Intentionally deleted”.

Regarding the different interpretations inside EUG on what are the functionalities an ERTMS/ETCS on-board constituent must comply with:As stipulated by the SRS clause 1.7.1.2 (“The ERTMS/ETCS on-board equipment shall implement all mandatory requirements, with the only exceptions and conditions explicitly stated in the Control-Command and Signalling TSI and in this SRS.”), the detailed answer can be found in the TSI CCS itself. There are explicit mentions of the functionalities or interface specifications which are optional, possibly depending on the application level, and without which a full certificate of conformity can be granted. Then after, it will be possible to integrate such ETCS on-board IC in a train, depending on the application level(s) this train is equipped for.

UNISIG 03/11/14The solution proposal posted by ERA on 27/10/14 is agreed.

EECT 04/11/14The ERA solution proposal 27/10/14 is also agreed by EUG.

Supporting document(s) for Justification/Discussion for SolutionPreliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

EEIG (ERTMS users group)

Contact person name R. DijkmanContact Person e-mail adress rdijkman@ertms.beEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number EEIG411List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassification

Reason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2014-01-06 04:56:49 PMLast modification date 2016-01-06 04:11:00 PM

Identification number 1237State Presented_to_ECHeadline KMS evolutionImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References Subset-038 V300Error/Enhancement EnhancementProblem/Need description This is the cover CR for the introduction of new documents and the

modifications to the ERTMS specifications that will be required to support the evolution of the key management system (KMS). The KMS Evolution objective of improving the KMS standards means not only to improve the specifications of KMS but also to improve for example the overall governance, process and security.The KMS specifications will be developed according to the following principles:• The technical specifications must be developed to support the overall KMS Evolution concept, which includes both technical and non-technical aspects.• The KMS Evolution strategy aims for a system with an improvement of the current KMS rather than an introduction of new KMS• The system shall allow for online connectivity and distribution between KMS entities and ETCS entities

Supporting document(s) for problem/need descriptionSolution Proposal by submitterSupporting document(s) for solution proposalAgreed Solution Add new item 83 (SUBSET-137) in the TSI CCS annex A, with

content as per attachment "SUBSET-137 v032.docx"

Modify SUBSET-023 v3.1.0 as described in the attachment "Solution_for_CR1237_S23part_161215.docx"

Modify SUBSET-026 v3.4.0 as follows:add a new item h) in clause 2.5.1.1 to read: "Public Key Infrastructure (PKI)"add a new section 2.5.1.9 with title "PKI"add a new clause 2.5.1.9.1 to read: "The role of the PKI is to manage and distribute digital certificates, so as to allow a secure on-line distribution of cryptographic keys between KMCs and from a KMC to the ERTMS/ETCS entities (ERTMS/ETCS on-board equipments, RBCs and RIUs).".Modify chapter 2 figure 1 as follows:add the label "SUBSET-137" to the lines where the labels SUBSET-114 and SUBSET-038add a new box "PKI" with lines labeled "SUBSET-137" to the 4

boxes "EURORADIO" and to boxes KMC1 and KMC2

Modify SUBSET-104 v3.2.0 as follows:In table 4.3.2.2, add a new line with the following content: "83", "SUBSET-137", "On-line Key Management FFFIS", "N".

Modify SUBSET-038 v3.0.0 and SUBSET-114 v1.0.0 as described in the attachments "SUBSET-038 v301.doc" and "Subset-114 v101.doc"

Supporting document(s) for agreed solution

Solution_for_CR1237_S23part_161215.docxSUBSET-137 v032.docxSUBSET-038 v301.docSubset-114 v101.doc

Justification/Discussion for Solution

EUG 17-10-2014The current status of the TEN-T KMS Evolution project is presented by means of the following draft deliverables (see attachment "KMS_draft_20141017"):• Strategy KMS Evolution• FRS KMS Evolution (appendix B to be submitted/included Oct 20th)• ORS KMS Evolution

These documents are the result of a 14 month process of the EUG KMSe WG, including 3 joint meetings with UNISIG (May, June, July 2014). The content of the documents has been aligned with the KMS related recommendations from the KPMG report ‘IT Security Threat identification, Risk Analysis and Recommendations’, however focussed on on-line KMS.

At this moment the status is considered as ‘draft’ as UNISIG will have their coming review round end of October 2014.

During the joint June meeting with UNISIG it was agreed that UNISIG would start working on the FFFIS ‘on-line KMS’ based on the June FRS version. This FFFIS, which is the fourth deliverable of the TEN-T project, will be developed in an iterative process, based on the evolving FRS and ORS.

As can be read in the FRS document, one subject is still pending:• The mandatory inclusion of both off-line and on-line capabilities or only one of them in the OBUs. This is planned to be discussed with CER.

EUG 22-10-2014The rationale for the choice of the security protocol added. See attachment "14E157-0b_KMS_Evolution_SC_20102014". It is the appendix B of the FRS, as mentioned in the 17-10-2014 entry.

UNISIG SG 17/12/14See attachment "CR1237 - SG20141217.zip" for the UNISIG Super Group comments on the documents 14E035 "KMS Evolution Strategy" version 0C, 14E039 "KMS Evolution FRS" version 0L and 14E040 "KMS Evolution ORS" version 0F.

EUG 25-02-2015

See attachment "CR1237 EUG replies 20150223" for the EUG replies to the comments of UNISIG posted on 17-12-2014.See attachment "CR1237 KMS specs 20150225" for the updated draft KMS specification documents. These updates include the accepted UNISIG SG comments and some further work on the KMS specs which has been performed based on discussions between the EUG KMS WG and the UNISIG KMS WG before the UNISIG SG comments were received.The main principles which still have to be defined are the following.1) The triggering event for the communication between the ETCS onboard and the KMC. This topic is still in discussion and the actual status will be presented in the March EECT meeting.2) The APN for the KMS communication. EUG prefers a separate (from ETCS) APN, to facilitate a smooth and efficient KMS communication. Since the priority of the KMS communication is at the same level as for the ATO, both could possibly share the same APN, but this can be further discussed in the March EECT meeting.

EECT 10/03/15The following open points for the FFFIS are reviewed and agreed as follows:• Use of APN: EUG wants to use one of the two ETCS mobiles, however it is agreed to use an APN distinct from the one used for the ETCS application (i.e. EVC <=> RBC/RIU). • New Subset or extension of SUBSET-114: It is agreed to keep the scope the SUBSET-114 unchanged and to create a new SUBSET for the FFFIS on-line key management• ATO Keys: further to the decision taken in the frame of the CR1238, the ATO trackside and ATO OBU will be two new KM entities and this needs to reflected in both SUBSET-114 and FFFIS on-line Key Management• It is confirmed that the on-line Key Management is only applicable for PS areas.

Regarding KMAC renewal triggering event, EUG proposes the following simplified solution proposal:• at power on• every x hours, x being configured in the on-board and determined by the home KMC.• on maintenance request

FFIS TLS with or without PKI:EUG requests the PKI as a mandatory feature while UNISIG would like to keep it optional, i.e. to keep open the possibility to use PSK (pre-shared keys) instead of PKI. UNISIG will draft this part in a dedicated section of the FFFIS so that a decision on the PKI architecture can be taken later on without impacting significantly the rest of the document.

Security level for the KMS:EUG requests a statement about how to deal with cyber security (Use of Common Criteria for cyber secure development process). UNISIG explains that they do not agree on putting cyber security process requirements inside the FFFIS as this subset will specify only the interface. Any addition of such process requirements has to be justified technically and economically. UNISIG also underlines

that the EUG request does not always match the requirements in call for tenders / contracts of the railways. EUG explains that this is coming from the outcome of the KPMG study, which in their view clearly indicates the impact on ERTMS safety if certain security measures are not taken, and as well as from the WP description of the TEN funding. ERA clarifies that the security is for sure not in the scope of this CR, which is only the delivery of a FFFIS.

UNISIG agrees that the previous review round is closed (even if not agreeing to all the EUG replies) and will instead focus on review of the updated documents, possibly repeating ‘old’ comments.

EUG 24-04-2015See attachment "CR1237 EUG attachments 20150424" for an update of the user requirements on KMS.• FRS .0N, one clean and one with track changes against .0M• 14E157.0C, Annex B to FRS, one clean and one with track changes against .0B• ORS .0H, one clean and one with track changes against .0G• EUG KMse WG response/review to UNISIG FRS .0M review• EUG KMse WG response/review to UNISIG ORS .0G review

In general:• These new versions contain agreed changes from the review sheets.• These new versions contain latest additions with respect to triggering and ATO KMS entities• The FRS Annex B document 14E157 has been updated with the EUG position on TLS with PSK• Furthermore detailed scenario diagrams have been added to the ORS Annex A, explaining relation with KMS systems/roles.• The security references [CC] and [ENISA] are now noted as ‘recommendation’

UNISIG 11/05/15See attachment "Action 07.11b - 20150511.docx" for the assessment of the EUG proposal for KMAC triggering events.

UNISIG 22/05/15See attachment "On-line KMS Subset 0.1.0.docx" for a first version of the FFFIS on-line KMS

EUG 02/06/15 See attacment 'Online_KMS_Subset_0.1.0_Review_Sheet_EUG' for the EUG comments to the first version of the FFFIS on-line KMS.

UNISIG 04/06/15See attachment "U comments on FRS 0N and ORS 0H.zip" for UNISIG comments on FRS .0N and ORS .0H posted by EUG on 24/04/15.

ERA 05/06/15See attachment "Online_KMS_Subset_0.1.0_ERAreview_050615.docx" for the ERA review of the first version of the FFFIS on-line KMS tabled by

UNISIG on 22/05/15.

EECT 09/06/15UNISIG informs that their entry 11/05/15 (KMAC triggering events) has been taken into account for version 0.1.0 of of the FFFIS on-line KMS.

The ERA/EUG comments on the document “On-line KMS Subset 0.1.0.docx” are discussed (See attachments "Online_KMS_Subset_0.1.0_ERAreview_EECT090615.docx" and "Online_KMS_Subset_0.1.0_EUGreview_EECT090615.docx" for details.Note: for the ease of the discussion of the EUG comments, the file provided by UNISIG with preliminary answers is used and amended during the meeting (see revision marks in the attachment "Online_KMS_Subset_0.1.0_EUGreview_EECT090615.docx").

During the review of the ERA comments, an additional one is raised: what is the expected behavior if the ETCS on-board needs to abort a communication with a KMC because it needs back the MT for ETCS purpose (e.g. approaching an CS only trackside area)? UNISIG already clarifies that the communication will be released by the OBU without informing the KMC. However, UNISIG agrees that this behaviour should be reconsidered.

EECT 09/07/15EUG and UNISIG completed in a bilateral meeting the FFFIS review prior to the meeting. However ERA spots a few leftovers (see review comments highlighted in yellow in the attachment "Online_KMS_Subset_0.1.0_Rev_Sheet_EECT090715.docx") where there are misalignments between the final reply and the text in the answer column.Regarding the expected behaviour in case of abortion by the on-board of the KMC communication: UNISIG can already mention that they have a draft proposal of using a different timer (10 minutes) for the time to retry in case a key session has been aborted.

EUG 01/09/15In relation to the CR741, see attachment "EECT_Action_11_08_CR1237.docx" for a clarification of the KMS PS service setup.

UNISIG 23/09/15See attachment "Subset-037 v312.docx" for the updated version (v0.2.0) of Subset-137 “On-line Key Management FFFIS”. See attachments "Online_KMS_Subset_0.1.0_ERAreview_220915.docx" and "Online_KMS_Subset_0.1.0_EUG_Review_final.docx" for the related review sheets.

EECT 06/10/15Further to the issuance of SUBSET-137 v0.2.0, EUG has submitted a new batch of comments. The outstanding ones are discussed; see tags “EECT061015” in the attachment "Online_KMS_Subset_0.2.0_Review_EECT061015.docx".

Concerning EUG comment #6 (linked on ERA comment#2 on

version 0.1.0) : ERA clarifies that to split the table of references had never been requested. On the contrary, it is agreed to have just one single list of references in the document (i.e. to not use any longer the old fashioned terms “informative” and “normative”). A reference is mandatory only if it is explicitly stated in the core of the document.Moreover, ERA also highlights the two following quality issues: - the clauses 3.3.1.1 and 3.4.1.1 on top of the Acronyms/Abbreviations and Terms/definitions“ tables are wrong. Actually these clauses should be formulated the other way around, i.e. they should be formulated as e.g. in SUBSET-039. - some acronym (e.g. APN) are as a matter of fact common to at least 2 documents, they should therefore be only listed in SUBSET-023 and removed from the concerned documents.

Regarding the clarification of the KMS PS service setup”(see EUG 01/09/15):

The paper posted by EUG is reviewed, see attachment "Action_11_08_CR1237-EECT061015.docx".In particular for the part regarding the introduction of Multiplexing technology on the interface between EVC and the MT: considering that anyway the MT will have to be enhanced with at least EGPRS and that to make it mandatory for the MT only does not make any sense if inter-changeability is to be kept, ERA decides that it will be mandatory for both the ETCS on-board and the MT. It also obviously makes more easily room to upcoming or other future IP based functions.However UNISIG ER WG considers that there could be unclear requirements in ETSI 27.010 that could hamper the certification of the ETCS on-board equipment.Post meeting note: further to an email exchange with I. Wendler, it is also necessary to ensure that the MT is able to handle multiple PDP context at the same time; otherwise the multiplexing of the interface would make no sense.

Concerning the interface between Euroradio and KMS, UNISIG considers that a coordinating function inside SUBSET-037 shall be implemented for managing the KMS resources between the Security Layer and the User Space.

UNISIG 28/10/15See attachment "CR1237 - 20151028.zip". This attachment contains:- Version 0.3.0 of Subset-137- UNISIG answers to EUG comments on version 0.2.0 of Subset-137 - The result of action 14.06 "To draft a list with all the abbreviations/definitions/acronyms to be incorporated in SUBSET-023 concerning CR 0741 and CR 1237".

EECT 04/11/15Regarding the SUBSET-137:The modifications implemented in SUBSET-137 0.3.0 are presented by UNISIG.In particular, the section 7.2 is heavily questioned because it is not clear how an end-to-end connection could be established between the on-board and a Certificate Authority (CA) or a Registration

Authority (RA), which can be anything like e.g. governmental organisations. It is therefore clarified that : - For Key Management, to access the Home KMC (and also CA and RA) will always be done via the Home GGSN. UNISIG indicates that the values mnc and mcc will be taken from the IMSI. This does not change anything on the communication side. - the domain “.etcs” shall only be used for ETCS entities and KMC, not for the CA or the RA. - the home network shall be responsible through its KMS DNS to resolve the FQDN of both the CA and RA. - The QoS parameters for non-ETCS applications will be specified only in the EIRENE SRS and not in the SUBSET-137. It has to be requested “as subscribed”, i.e. the EVC should not ask in the PDP context activation for specific values.To take into account the above, the section 7.2 is reworked accordingly (see part highlighted in blue in the attachment "Online_KMS_Subset_0.3.0_EECT041115.docx") together with the necessity to modify the EIRENE SRS concerned clauses to reflect that.

Another modification not resulting from the previous actions/decisions is also introduced by UNISIG, which consists of the suppression of “abort” message. This modification comes from a divergence between the KMS WG and the ER WG, which has been arbitrated by ERA and which was resolved just before the issuance of this version 0.3.0.Post meeting note: a memo (see attachment "Management of KMS priority over IP.docx"), drafted after the resolution of this issue, describes this latter and justifies the suppression of the “abort” message.

Regarding the SUBSET-037:The necessary modifications induced by the CR1237 have been implemented by UNISIG in the SUBSET-037, mainly the priority management of communication resources (new section 8.5) and need not any further discussion.

Regarding the action to draft a list with all the abbreviations/definitions/acronyms to be incorporated in SUBSET-023 concerning CR 0741 and CR 1237):The paper drafted by UNISIG (28/10/15) is not reviewed (lack of time). However it is expected that its content is not controversial and it will be reviewed after the meeting by ERA and most likely incorporated as such in the SUBSET-023. Any further comment will then be addressed in the frame of the B3R2 documentation review round.

Others:In addition the modifications to the following other documents have been overlooked so far: - SUBSET-026 chapter 2 figure 1: wherever the labels SUBSET-114 and SUBSET-038 are present, the label SUBSET-137 must be added - SUBSET-104 table 4.3.2: a new line “SUBSET-137” needs also to be added with a “N” in the “Impacting” column.

ERA 11/11/15Regarding the impact on SUBSET-026 chapter 2 figure 1: in addition to the existing arrows where "SUBSET-137" must be added, the interface between the KMS entities (KMC, RBC, RIU, OBU) and the PKI needs also to be indicated. To that effect the acronym PKI and its corresponding definition must be introduced in the SUBSET-023 and not in the SUBSET-137.We have also the following remark on the UNISIG proposal (28/10/15) for the modifications to be brought to SUBSET-023: for the entry "OBU" in the abbreviations table, the rightmost cell should read "On-Board Unit".

Regarding all the necessary provisions for the Packet Switch services, which are induced by this CR: they are taken into consideration in both the EIRENE SRS and SUBSET-037, in the frame of the CR741.

EECT 08/12/15The following amendments to the solution 11/11/15 are agreed.

SUBSET-023 part:- SUBSET-037 shall be removed as reference in the definition of "Authentication Key". Not any definition refers to sub-documents.- For most of the definitions introduced the dot at the end of the sentence is missing.- OFF-LINE KMS is using the term “target device”. Both terms OFF-LINE KMS and ON-LINE KMS should preferably be aligned by using the same kind of wording => Modify ON-LINE KMS to read: “KMS allowing remote distribution, deletion or updating of key entries in the target device”See attachment "Solution_for_CR1237_S23part_161215.docx " in the field "Agreed Solution"

SUBSET-026 part: To be in line with the updated chap 2 figure 1, a new item h) in clause 2.5.1.1 and a new section 2.5.1.9 describing PKI shall be added.

SUBSET-137 part: see ad-hoc table in the attachment "B3R2_Udocs-consolidated review sheet_final.docx" and the resulting version 0.3.2 of SUBSET-137 in the field "Agreed Solution".

Moreover the following impact on SUBSET-038 and SUBSET-114 are agreed:SUBSET-114 § 4.6. is confusing in the framework of B3R2 and should be removed from the SS-114.SUBSET-114 § 5.1.1.2 should also be deleted.Sections “Abbreviations and Definitions” to be aligned with SUBSET-023, both in SUBSET-038 and SUBSET-114See field "Agreed solution" for the necessary changes to SUBSET-038 and SUBSET-114

Supporting document(s) for Justification/Discussion for Solution

KMS_draft_20141017.zip14E157-0b_KMS_Evolution_SC_20102014.docxCR1237 - SG20141217.zipCR1237 EUG replies 20150223.zipCR1237 KMS specs 20150225.zipCR1237 EUG attachments 20150424.zipAction 07.11b - 20150511.docxOn-line KMS Subset 0.1.0.docxOnline_KMS_Subset_0.1.0_Review_Sheet_EUG.docxU comments on FRS 0N and ORS 0H.zipOnline_KMS_Subset_0.1.0_ERAreview_050615.docxOnline_KMS_Subset_0.1.0_ERAreview_EECT090615.docxOnline_KMS_Subset_0.1.0_EUGreview_EECT090615.docxOnline_KMS_Subset_0.1.0_Rev_Sheet_EECT090715.docxEECT_Action_11_08_CR1237.docxSubset-037 v312.docxOnline_KMS_Subset_0.1.0_ERAreview_220915.docxOnline_KMS_Subset_0.1.0_EUG_Review_final.docxOnline_KMS_Subset_0.2.0_Review_EECT061015.docxAction_11_08_CR1237-EECT061015.docxCR1237 - 20151028.zipManagement of KMS priority over IP.docxOnline_KMS_Subset_0.3.0_EECT041115.docxB3R2_Udocs-consolidated review sheet_final.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

EEIG (ERTMS users group)

Contact person name R. DijkmanContact Person e-mail adress rdijkman@ertms.beEndorsed by Recognised Organisation(s)Project Information The basis for this CR is the activity performed by EUG and UNISIG

on KMS in the WP8 of the TEN-T action 2012-EU-60022-S "Facilitating and speeding up ERTMS - Second phase".

Submitter Reference Number EEIG430List of assigned WG(s)Severity Performances impact, non interoperability and non safety relatedTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2014-05-27 11:04:07 AMLast modification date 2016-01-06 04:11:01 PM

Identification number 1242State Presented_to_ECHeadline Several problems with STM specificationsImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References 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.0Error/Enhancement ErrorProblem/Need description 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.

Supporting document(s) for problem/need description

Attachment_problems_STM_spec_20140722.doc

Solution Proposal by submitter See document "Attachment_problems_STM_spec_20140722.doc" in the field "Problem/Need".

Supporting document(s) for solution proposalAgreed Solution 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_161215.docx"

Supporting document(s) for agreed solution

Solution_for_CR1242_161215.docx

Justification/Discussion for Solution

ERA 10/12/14:See embedded comments in attachment "Attachment_problems_STM_spec_20140722_revERA.doc" for the ERA review. The items without any remarks are agreed.

EUG 19-12-2014We are not experts in these detailed STM specifications. Therefore we did not do a detailed review. We just expect UNISIG to answer the comments made by ERA and we have one editorial remark. To avoid misunderstandings we propose in item 12 in clause 9.2.1.3 in the sentence between brackets to change "it" to "the STM". For the experts this may seem obvious, but it does not do any harm to be as explicit as possible in these specifications.

EECT 14/01/15The ERA/EUG comments are reviewed during the meeting:- Item #2: UNISIG explains the underlying reason of the proposed modification: there is no mandatory use by the STMs to use the packet 43 and some STMs do not in case the National System requirement consists of displaying only the speed pointer (i.e. no CSG, target speed, …).The proposed modification is by intention a bit provocative to force the STM suppliers to use the packet 43, especially when the National System requirement consists of the display of the sole speed pointer, but in a colour different from grey since the packet 43 can be tailored to display only the speed pointer on the ETCS DMI. It has been observed that the situation where the mode is SN but no packet 43 has been received by the DMI Function is also existing in

case of immediate level transition without announcement, until the STM reports DA. This situation could occur whatever the STM design is. Conclusion: the UNISIG proposal (slightly amended) is accepted.- Item #7: withdrawn by UNISIG as proposed by ERA- Item #10: the ERA comment is acknowledged by UNISIG and the enhancement proposed by UNISIG is accepted with a slight modification.- Item #12: the editorial improvement proposed by EUG is accepted- Item #14: it is confirmed that it is fully superseded by CR1094

Conclusion: the solution proposal, with the above amendments, is agreed. See attachment "Attachment_problems_STM_spec_EECT140115.doc" and resulting solution in the attachment "Solution_for_CR1242_140115.doc".

EECT 08/12/15The following amendments to the solution 14/01/15 are agreed:- SUBSET-058 v3.1.0 part: impact on section 7.2.4 to be withdrawn and impact on 7.5.5 to be added for X_TEXT length- SUBSET-059 v3.0.0 part: impact on table 5.2.10.21 instead of 5.2.10.2 and for consistency, add "see 5.2.10.2" in the table 5.2.10.21

See parts highlighted in blue in the attachment "Solution_for_CR1242_161215.docx" in the field "Agreed Solution"

Supporting document(s) for Justification/Discussion for Solution

Attachment_problems_STM_spec_20140722_revERA.docAttachment_problems_STM_spec_EECT140115.docSolution_for_CR1242_140115.doc

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name L. RepettiContact Person e-mail adress luca.repetti@ansaldo-sts.comEndorsed by Recognised Organisation(s)Project Information reference baseline is actually B3 MR1Submitter Reference Number List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2014-07-01 06:38:34 PMLast modification date 2016-01-06 04:11:01 PM

Identification number 1245State Presented_to_ECHeadline Display of ETCS override in level NTCImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References Subset-026 V340

Subset-035 V310ERA_ERTMS_015560 V340

Error/Enhancement ErrorProblem/Need description 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 descriptionSolution Proposal by submitterSupporting document(s) for solution proposalAgreed 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:

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 solutionJustification/Discussion for Solution

UNISIG 17/12/14The ETCS override is a safety related function. The SG opinion is therefore that an indication has to be given to the driver when this

function is active.Passing a border to a level different from NTC without MA is an ETCS aspect and is different than passing a national signal at stop only.SG therefore considers that the combined activation of national override and ETCS override has to be a separate command (i.e. a separate “button”) than the national override activation.Having two separate buttons will solve the problem described in the CR since the ETCS override function will not be activated (and therefore no ETCS override display will take place) when passing a national signal at stop out of a level transition context (the driver will select the national override button and not the combined activation button). This means that no change to the existing ETCS functions is needed.Note: the requirements for the combined button need to be defined. This button could be required to fulfil the same safety requirements as the ETCS override button.

EUG 19-12-2014It is not entirely clear but if we understand UNISIG well they propose that there should be 3 different buttons. One to activate the NTC only override, one to activate the ETCS only override and one to activate both NTC and ETCS override at the same time (the so called combined button). If that interpretation is correct, then we have from an operational perspective strong doubts that it is the right way to go. It does not look good to us, but that would obviously have to be confirmed by OPE experts.Independent of what we think about the UNISIG proposal, we do not see the relation with the problem description. Our concern is that pressing the NTC override button could result in the display of the ETCS override symbol. The introduction of a new button does not address this concern.

ERA 08/01/15We share the same interpretation and the same strong doubts as EUG regarding the UNISIG proposal 17/12/14. Moreover, for transitions NTC X => NTC Y it is a fact that, as long as in level NTC X, the STM Y cannot display anything regarding its override status after it has been activated through the STM X override activation broadcast. We do not see why it would pose a problem for transitions NTC X => levels 1/2/3.

EECT 14/01/15Even though the problem depicted by the CR was recognised and validated in the triage, UNISIG finally changed their mind and challenged it for the case the driver has to activate both national & ETCS override (if needed to both pass a national signal and enter in level 1, 2 or 3). They consider that, when an override is active in a given system, the corresponding status shall be displayed for safety reasons regardless the system is the supervising one or not. They consequently propose 3 different override buttons, the national one, the ETCS and a combined one for passing level transitions (see UNISIG proposal 17/12/14).

ERA/EUG do not support the UNISIG proposal 17/12/14. It is

recalled that what operationally matters for the driver is to be able to override a stop location on the track, which is materialized by either a signal or a stop marker board and by an EOA when the line is fitted with ETCS. The driver should therefore, further to a written order, depress one single override button and be given one single indication, namely the ones of the supervising system, because he has to follow the national rules and only the national override status is relevant, even though the ETCS override is prepared in the background for taking over the train supervision in case a level transition towards ETCS is going to be crossed.With the FFFIS STM, the single override selection is achieved through the broadcast function (supervising system towards the other ones). While the CR submitter aims at achieving the single indication when an STM is the supervising system, U argues that when the ETCS override button is depressed, this information is also broadcasted to the National Systems which would be responsible to avoid the double indication but they cannot be covered by the ETCS specifications.

According to UNISIG, the combined button and the double indication would be useful in case the level transition is not close to the signal to be overridden, but rather in the middle of a block section. In such case the indication of the ETCS override status would allow the driver knowing if he is able to cross the level transition without being tripped.ERA reminds that a driver does not override level transitions as such. If an override is used in the context of a level transition, it is still because the level transition location is also a potential EOA, which means that either the level transition inside a block would be a separate stop location to be duly considered de facto as block subdivision, or the ETCS override parameters should be engineered in such a way to keep the ETCS override active until both the signal and the level transition are passed, or it is a matter of engineering to ensure that the train is not tripped while passing the level transition if the override is no longer active.

It is agreed that EUG will draft a table showing all the possible combinations for the override indications depending on level transitions and the use of existing buttons (one for national system and one for ETCS system). In addition, it could be investigated why, in case National System interfaced through the FFFIS STM, 2 distinct override selections are offered to the driver and whether this should not be better to get only one single selection as well.

EUG 04-02-2015The attachment "CR1245 20150204.docx" defines the override symbols in the different level transition scenarios.We started from the principle that only the indication related to the current level should be shown. We detected however certain scenarios where we considered that a compromise would be necessary. These are shown in the table. We will clarify this further in the next EECT meeting.

EECT 11/02/15The EUG homework (see attachment "CR1245 20150204.docx") is reviewed.

For the case of a level transition announcement from NTC to ETCS stored on-board and the NTC override button is depressed, the Agency stresses that showing both ETCS and National override statuses contradicts what EUG has defended until now. EUG explains that in Austria and Germany the current PZB operating rule allows to accelerate after passing the signal and that if the ETCS override status icon would not be shown then on passing the level transition border he might be caught by override ceiling speed supervision .that he should not accelerate because there is an ETCS transition on-going.The Agency also remarks that the note (6) in the EUG document, for what concerns the selection of the ETCS override button and the display of the NTC override status, is incomplete: it is also necessary that the STM implements the processing of the STM packet-7 (“override status”). This is also illustrated by a survey provided by the STM WG (see attachment "STMWG_survey_CR 1245.msg") showing that only half of the STM do process the packet 7.As a result, the note (6) needs to be replaced with a note (7) in the concerned rows, adding the above mentioned supplementary condition (see attachment "CR1245_EECT 110215.docx").

UNISIG 27/02/15The following modifications are proposed to Subset-026 v3.4.0:Add new SRS clause 5.8.3.7.1 to read “Exception 1: in case the Override function has been activated by an STM (see Subset-035) and the level is NTC and no transition to level 0, 1, 2 or 3 is announced, the status “override active” shall not be indicated to the driver.”

Add new SRS 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 if the level NTC is entered.”

The following modification is proposed to ERA_ERTMS_015560 v3.4.0: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]).”

EUG seems to require that the STM shall display an NTC Override symbol (see file "CR1245_EECT 110215.docx"). Even if it is the case in all existing implementations today, there is no requirement on the STM to do so. We are therefore wondering whether, in addition to the modifications proposed above, such a requirement should be added to SUBSET-035.

EUG 04-03-2105We have previously introduced the display of the ETCS override symbol in the level NTC area when NTC override is selected in the LNTC > ETCS scenario. The condition for the ETCS symbol to appear was that the level transition is announced. This solution was a compromise. See the descriptions in the entries EUG 04-02-2015 and EECT 11/02/15.Further analysis in the concerned railway (DB) revealed that it is not

always feasible to transmit the level transition to the ETCS onboard before the driver uses the override button. The route is probably not set, therefore it may not be known if the train will pass the level transition or not. As a conclusion DB does not see this as a useful feature. As a consequence they accept that the problem of the potential acceleration above the ETCS speed which would be supervised after the level transition has to be solved by operational rules related to the operation of the concerned NTC.This means that the ETCS override symbol with the condition of the level transition could be removed from the EUG functional description. See the update in the attachment "CR1245_EUG_150304". Based on this update we propose the following modification to the UNISIG solution proposal of 27/02/15.Modify the proposal for the new SRS clause 5.8.3.7.1 to read “Exception 1: in case the Override function has been activated by an STM (see Subset-035) and the level is NTC, the status “override active” shall not be indicated to the driver."The rest of the UNISIG proposal can remain as it is.Regarding the UNISIG remark. EUG does not require that the STM displays the NTC override symbol. That is obviously a decision for the authority responsible for the specific NTC. We indicated this with notes (6) and (7).

EECT 10/03/15Further to the EUG statement 04/03/15, the UNISIG solution proposal 27/02/15 is slightly amended. It is also agreed to modify the wording of the clause 5.8.3.7.2 (“on executing a transition to level NTC” instead of “if the level NTC is entered”). The agreed solution consists therefore of the following:

- Add new SRS 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 SRS 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 clause 8.2.3.1.9 of ERA_ERTMS_015560 v3.4.0 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 Justification/Discussion for Solution

CR1245 20150204.docxSTMWG_survey_CR 1245.msgCR1245_EECT 110215.docxCR1245_EUG_150304.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

EEIG (ERTMS users group)

Contact person name R. Dijkman

Contact Person e-mail adress rdijkman@ertms.beEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number EEIG432List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2014-07-10 05:50:00 PMLast modification date 2016-01-06 04:11:01 PM

Identification number 1249State Presented_to_ECHeadline Problems with pre-indicationImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-026 V340Error/Enhancement EnhancementProblem/Need description See the detailed description in attachment "EEIG435 20140917 pre

indication".Supporting document(s) for problem/need description

EEIG435 20140917 pre indication.rtf

Solution Proposal by submitter The solution should reduce the time display between the preindication and the indication curves in such circumstances.

Supporting document(s) for solution proposalAgreed Solution Modify SUBSET-023 v3.1.0, SUBSET-026 v3.4.0, SUBSET-027

v3.1.0, ERA_ERTMS_015560 v3.4.0 as described in the attachment "ERA_solution_for_CR1249_110516.docx"

Supporting document(s) for agreed solution

ERA_solution_for_CR1249_110516.docx

Justification/Discussion for Solution

ERA 01/04/15See attachment "ERA_solution_proposal_for_CR1249_010415.docx" for the detailed solution proposal.Note that this solution proposal must be considered in conjonction with the updated solution proposal of the CR1107 and with the solution proposal of the CR1187.

UNISIG 08/04/15Our opinion is that the ergonomics experts and operational experts have to be consulted before an agreement can be reached on the principles of the solution proposed by ERA (see ERA’s posting dated 01/04/15).The pre-indication is an information to the driver that the train is approaching a target.This information includes the distance to target the train is approaching and the speed value of this target.

By “substituting” the pre-indication with the planning area, this precise “pre-information” about a target is lost because the way it is displayed in the planning area does not provide a precise information about which target is supervised and the distance to the supervised target. It does not provide either the speed value of any target (except for the first target at zero speed).UNISIG therefore considers that ergonomics experts and operational experts should say whether this lack of precise information on a target as long as TSM is not reached is acceptable or not.

The pre-indication is accompanied with the generation of the sound Sinfo.The generation of this sound Sinfo aims at informing the driver of some new visual information, drawing the driver’s attention to the DMI. In this case, the new visual information alerts the driver of an approaching target.Removing the pre-indication means that the sound Sinfo would be generated for the first time when entering in TSM.This means that a driver mainly looking at the track could be “surprised” by a target appearing on the area B of the DMI and for which an “immediate” reaction from him/her is requested. In order to avoid such surprises, the driver may be inclined to adopt a more head-down driving style, checking the DMI more frequently that would be the case today.We consider that the opinion of ergonomics experts and operational experts is also needed on this point.

UNISIG also wonders whether the solution proposed by ERA is compatible.Would an on-board without this CR be typically authorised to run on the Paris-Lyon line? Probably that the answer to this question is “no”.

Some other remarks:- The term “perturbation location” does not sound to UNISIG as being the most appropriate. We however do not have for the moment an alternative proposal.- The justification for the re-opening of CR1107 reads as being not related to CR1249 (see text “Considering the arguments given by the submitter in the "field problem/need description" (amongst others: "....planning information provides an essential element of drivers information...."), it is obvious that there is no reason to keep the possibility for the driver to toggle off the display of the planning information” in the “Justification/Discussion for Solution” field of the CR). This does not reflect the reality. The CR1107 has been re-opened due to CR1249. The modifications contained in updated solution proposal for CR1107 could also be part of CR1249 solution proposal. The CR1107 could then be superseded by CR1249.

We have not yet reviewed the details of ERA’s solution proposal for this CR and related updated solution proposals for CRs 1107 and 1187. We will do that once the principles of CR1249 solution will be agreed.

EUG 14/04/15In our view the CR requires careful consideration from an

operational point of view. A simulation similar to the ones performed on the context of CR1084 will be useful to verify possible solutions. In addition, due to the time available, it has not been possible to define a consolidated position before the EECT. However, we have received feedback from some of the EUG members. We would like to share this input in order to have some fruitful discussions on the next EECT. See attachment CR1249_EUG_150414.

EECT 15/04/15Regarding the UNISIG statement 08/04/15, ERA challenges two assumptions, which are in their view incorrect: 1) “The pre-indication is an information to the driver that the train is approaching a target”: the primary purpose of the pre-indication (see SRS clause 3.13.9.5.1) is not to show the target information itself, but to alert the driver that he is going to be invited to operate the service brake, no matter the target speed/distance are. Therefore the indication marker on the planning info can be seen as continuous replication of the pre-indication. 2) “This means that a driver mainly looking at the track could be “surprised” by a target appearing on the area B of the DMI”: First of all this assumption is not in line with the definition of the cab signaling (see TSI OPE annex A), which says that the driver shall observe the indications on the DMI and that he could look outside at times if an operational rule requires it. Of course when nothing happens on the DMI (e.g. flat MRSP with no track conditions) the driver will naturally not focus on the DMI all the time. However, even if the Sinfo would not be played anymore a fixed time before the Indication is reached, it looks doubtful that a driver used to drive with the planning info could travel a distance corresponding to the whole scale of the planning info without noticing that the indication marker has gone from the top to the bottom of the planning area. UNISIG highlights that what matters is not the whole scale of the planning info but what happens at the bottom of this one.

SNCF Réseau stresses during the meeting that the driver should be alerted in due time that he has to brake the train, even though he will see the yellow bar going down. The ERA solution is going in the good direction, but the complete removal of the PIM could lead to some issues, about driving and braking. Therefore, something to trigger the driver's attention some seconds before indication curve, at least a sound, should be included.

Moreover, it is confirmed that the UNISIG reservation about the compatibility of this CR (Would an on-board without this CR be typically authorised to run on the Paris-Lyon line?) is not justified because according to RFF a B3MR1 train will be authorised to operate, however only with off-peak slots. UNISIG then wonders if this is really compatibility: ERA clarifies that the compatibility assessment is only about the authorisation to put into service and not the granting of slots, which is anyway outside the scope of the Interoperability directive itself. Otherwise CRs like ATO or PS for ETCS would be obviously incompatible ones.

UNISIG 06/05/14See attachment "UNISIG_CR1249_COM_SGv1.0.doc" for the

comments on the ERA solution proposal posted on 01/04/15.

EECT 13/05/15The two following EUG comments on the ERA solution proposal 01/04/15 are discussed (see attachment "EUG Actions CR1249.docx"):

- Reservation 1) (use of pre-indication):Mr Levesconte (CER) explains the reason why a pre-indication, in the form of an audible and/or visual alert, should be maintained: in conventional signalling the driver does definitely not look at the DMI most of the time. The cab information is only secondary information while lineside information is the primary information. This is why if the driver is alerted by the Sinfo only when the indication marker reaches the bottom of the planning info, he might not be able to avoid at least an overspeed. ERA however observes that then driving in conventional signalling in ETCS FS mode is maybe not correctly reflected in the current definition of the cab signalling specified in the TSI OPE Annex A.Mr Levesconte (CER) also mentions the use of the pre-indication to “test” the efficiency of the brakes on the very first braking of the journey or in case of low adhesion conditions.

EUG has no consolidated position on the use of pre-indication or not. EUG explains that in low density lines where the MA is renewed from time to time it is indeed desired to have a pre-indication to draw the driver's attention while in high density lines the pre-indication is very annoying because it can happen at every block section before the MA is renewed. This is why EUG wants an alert which can be toggled on/off by the driver.Mr Pisek (CER) reports that in Austria, depending on ETCS on-board suppliers, some B2 trains are running without the pre-indication implemented while some are running with. However the drivers manage to accommodate equally to both situations. Mr Pisek (CER) also states that the driver should be anyway trained about the meaning of the pre-indication.

However, from the above and the previous discussions, it appears that today no one is able to establish a single and unified meaning of the pre-indication.

Moreover ERA makes the following observation: on high density lines the driver cannot be expected to prepare himself to brake at every block section just before the MA is renewed. This is valid either if he would observe a pre-indication or if he would pay all the time attention to the indication marker going down on the planning info. The routine to see the Indication marker going up on each MA renewal when it is close to the bottom of the planning info would for sure prevail on an unnecessary repeated preparation to brake. Therefore it is rather the Indication time between the P-curve and the I-curve which should be more carefully looked at. Actually the current formula (which fluctuated several times in the EEIG braking curves document) is even not correct when there is a GUI curve since the Indication time is currently taking into account the full service brake build-up time.Therefore ERA proposes, instead of a pre-indication which could be

toggled on/off by the driver, to suppress the current Indication time formula and to make it a configurable parameter, which should be solely determined by the Railway Undertaking. This will allow the RU to configure the Indication time it considers suitable for its desired operation, on the basis of the rolling stock characteristics, of how “soft” is the GUI curve and of the desired driving style.

- Reservation 2) (P speed disruption):On request by Mr Pisek (CER) it is clarified again why the CR1249 addresses a line capacity issue. Because the pre-indication is currently a “vertical wall”, when the train speed is significantly below the MRSP speed the pre-indication can appear for a significant time (40s) before the MA is renewed. In addition it is accompanied with a decrease of the P Speed, which negatively impacts the drivers’ behaviour and which de-facto makes them unable to achieve the required headway, as demonstrated by simulator test campaigns run by SNCF. The aim of the CR is therefore to avoid any such P speed decrease before the MA is renewed. This can only be achieved by keeping the CSM display as long as possible.Even in case of a dynamic pre-indication, such P-speed sudden decrease would also occur and the only way to avoid it is to come back to a fixed pre-indication, which would of course just consist in rejecting the CR as a whole.

The UNISIG comments (06/05/15) are reviewed, see attachment "UNISIG_CR1249_COM_SGv1.0_EECT120515.docx".Remark for comment #7: the comment is rejected without the full UNISIG consent.

ERA 27/05/15Based on the agreed UNISIG comments (see attachment "UNISIG_CR1249_COM_SGv1.0_EECT120515.docx") and on the ERA proposal to make the Indication time a fully configurable parameter,see attachment "ERA_solution_proposal_for_CR1249_270515.docx" for the updated ERA solution proposal, which will be the basis for a validation of the concept through a simulator test campaign.

EECT 10/06/15Concerning the addition of the target speed indication on the planning info, ERA has proposed three options, see attachment "Options for speed indication in planning area.docx".

EUG position: option 2 looks like the best solution, even if the ergonomics of the solution needs to be checked by simulations (to check that there is not too much information).CER position: there is a balance between CER members, who do not accept any of the options and those, who could only accept option 2. Option 1 and 3 are rejected.In addition, EUG indicates that with the option 1, the driver might misinterpret the indication marker as being the location where the target speed must be reached.ERA also informs that according to their independent operational expert, the option 2 is also the preferred one; however in their original view, the flag should also have been coloured in yellow,

together with the digits indicating the target speed. The principle of colouring the flag in yellow too is agreed.

Two other questions, which are not covered by the figures in the attachment "Options for speed indication in planning area.docx", are addressed: - UNISIG wonders whether the flag and the digits of the target related to the indication marker should come back to grey or remain yellow when TSM is entered. It is agreed that the yellow colouring of a flag and its digits related to the indication marker should only happen in CSM. - EUG wonders whether a flag indicating a MRSP speed increase should also be shown with digits: it is agreed that all the flags shall be displayed with digits regardless they are indicating speed decreases or increases

As a result, it is agreed to launch the simulation test campaigns with the option 2 and the above clarifications.

In relation to the last EECT meeting (13/05/15) EUG also reports that CER operational experts finally agree with the ERA proposal of having a parameterisation of the indication time by the RU, instead of a pre-indication which could be toggled on/off by the driver.

EECT 09/07/15On request by EUG, the BDK input received the day before the May EECT meeting is discussed (see attachment "CR1249 BDK input.docx")ERA underlines that almost the whole content of this paper had been taken into account (use of V_MRSP instead of V_MRSP-n) during the May EECT meeting and then materialised in the updated solution proposal 27/05/15. Actually only one clause remained to be checked in the light of the BDK consideration “Furthermore it should be considered to limit the trigger for an MA request to only one trigger. With the current solution proposal the OBU can send an MA request for both the d_mar locations relative to the perturbation locations calculated from the EoA and SvL”.The clause 3.13.11.8 is checked again and it is clarified that the trigger of MA request meant in this clause cannot be anything else than the start of the MA request sending by the on-board according to MA request parameters previously given by the RBC. With the use of “either...or”, it is clear that the first location met by the on-board will trigger this MA request sending and that the crossing of the second location will have no effect.

ERA 07/09/15See attachment "ERA_solution_proposal_for_CR1249_070915.docx" for the updated set of DMI modifications (see section 8.3.6 and all relevant figures throughout the document) as per conclusions of EECT meeting held on 10/06/15.In addition, a first set of simulations revealed a flaw in the DMI table 8: setting the color to “grey” in the lines “TSM/IndS” for the column “0 km/h <= Pointer < VTarget” has been overlooked.

EECT 08/09/15

EUG presents its intermediate report on the CR 1249 bundle validation (see attachment "15E116-1_Validation_report_CR1249_bundle.docx").Excerpt from the EUG intermediate report (section 5.2 –Results):” After watching the corresponding videos it was agreed that the operational behaviour of the solution proposal is correct in general. In particular there was agreement on displaying the target speeds in the planning area, the behaviour in situations with several targets and masked targets, the changed indication marker calculation and the falling hook effect.”However, the EUG report lists three potential issues on the ERA solution that were discussed during the validation meeting held on 27/08/15. 1) Although the overall positive feedback on the current solution proposal, there are mixed feelings among the railways regarding the complete deletion of the pre-indication. Especially the UK operational experts expressed their concerns on the fact that the information given in the planning area is “not conspicuous enough to be relied upon”. Some railways are closer to the UK position, and some did not consider the pre-indication as needed. Therefore the operational experts present at this meeting proposed to add on top of the existing solution proposal a dynamic pre-indication (some time, fixed in the specifications, before the indication) toggled by the driver, which should look like the existing one but would depend on the current train speed. EUG confirms (as stated in the report) that the toggling on/off by the driver should take place in order to meet different operational needs on different lines.Notwithstanding the fact that this proposed toggled pre-indication represents a substantial contradiction of the current solution proposal and its accompanying CRs (“the [mandatory] planning info is not conspicuous enough”), ERA indicates that considering the split of responsibilities between RU and IMs, no such line dependent functionality can rely on a driver data entry. In particular this would open the door to new national rules (possibly even line dependent), while ERA (together with the sector) is striving until now to eradicate the existing ones and to avoid new ones with the overall intent to harmonize also operations with ERTMS.

2) The operational experts recommended displaying only the target speed values on the planning info (i.e. not to show speed increases of the MRSP). ERA acknowledges this recommendation, however considers preferable to wait for the second part of the validation campaign (simulation runs at Simufer) before drawing any conclusion on this topic.

3) Several railways have problems with the introduction of a configurable indication time. In the validation meeting ÖBB was concerned about the configurable indication time, in case drivers working on trains from different railway undertakings or leasing companies, as they will have to adjust to a different behaviour each time. In addition this indication time makes the engineering of the line difficult since it is difficult to predict the behaviour of the train. And last, the configurable value in the on-board would not meet the operational needs for all scenarios, in the case of a train running on several lines.First of all ERA recalls that the behaviour of a train for what regards

its braking distance is always predictable because the relevant braking parameters contributing to this braking distance must be communicated by the RU prior any authorisation to put into service. In relation to item number 1, on the contrary a toggled pre-indication makes somehow the behaviour of the train unpredictable unless it is imposed through a national/line dependent rule. All in all this toggled pre-indication would simply consist of an hidden national value, which cannot see the light because only a compatible release is scheduled.ERA also recalls that the indication time represents only a small contribution to the overall braking distance calculated by the on-board equipment, which depends on many other parameters (nominal emergency braking deceleration values, on-board correction factors, guidance curve , calculation of the lambda, etc...) relying upon the Railway Undertaking itself. For instance, how flat the braking curves are may strongly depend on the way a Railway Undertaking operate his train with regards its brakes maintenance policy. Above all ERA also recalls that the meaning of the indication (unlike the pre-indication whose any harmonised meaning could never be tabled by the Railways) remains the same as before (i.e. it is the trigger for the driver to act on the brakes), even though some flexibility is left to the RU to determine the indication parameter. Although the main driver is the brake build up time, the determination of this indication time can also for instance depend on how soft the GUI curve is and of the driving style that is expected from the drivers.

As a result ERA confirms that the validation campaign shall be continued on the same basis as the one unanimously (including the CER operational experts) agreed in the June EECT, i.e. the ERA solution proposal dated 27/05/15 + option 2 regarding the speed indications on the planning area.

UNISIG 01/10/15See attachment "CR1249 - ERA_ERTMS_015560 part - U.docx" for comments on the part which contains the modifications to ERA_ERTMS_015560 v3.4.0, posted by ERA on 07/09/15".

EECT 07/10/15See replies tagged “EECT071015” in the Word comments inside the attachment "CR1249 - ERA_ERTMS_015560 part_EECT071015.docx", which address the comments raised by UNISIG on 01/10/15.With these last clarifications, the solution proposal is complete and likewise the other CRs (CR1107, CR1187, CR1084) that form with CR1249 the bundle that is currently undergoing a validation campaign, the CR can be formally closed (ERA decision), however with opposition from EUG.

EECT 08/12/15The report on the CR1249 bundle validation test campaign is presented by EUG and is discussed, see resulting amendments in the attachment "Validation_report_CR1249_bundle_EECT081215.docx".

In addition to the update of the clause 3.13.9.3.6.2 resulting from the

validation report, the following editorial amendments to the solution are agreed.SUBSET-026 part:- 3.8.3.2 a): The reference to 3.13.9.5 is to be replaced with a reference to 3.13.11- Figure 28 to be corrected by deleting “Pre-indication location”- Unlike what is stated in 3.13.9.1.1, the perturbation location is not defined in this chapter. It is defined in the new chapter 3.13.11 => delete completely the bullet “pre-indication location”- The figure 54 is not in line with figure 56 for the area below the release speed in the vicinity of the start RSM location. The I curve depicted in the figure 54 should therefore be in line with the one of figure 56 and reflect the horizontal part of the I curve in the vicinity of the start RSM location- 3.13.10.4.11 and 3.13.10.4.18: After “Note:” capitalise the beginning of the sentence.- tables 10&11: These tables are made mandatory from the clause 3.13.10.4.10.1 => Move them before 3.13.10.4.11- 3.13.10.6.1 table 15 condition [1]: In case no release speed is supervised (e.g. in case of LOA see 3.13.9.4.4), the sub-condition “(The train speed is above or equal to the release speed)” cannot be checked => modify the sub-condition [1] to add "In case a release speed is supervised"- together with the deletion of the figure 53, renumber figures 54, 55 & 56 to 53, 54 & 55 and then allocate the number 56 to the figure in 3.13.11.6, which will keep the figure numbers unchanged in the rest of chapter 3- 7.5.1.118.3: to be in line with the T_MAR description add a "the" before "perturbation”

DMI part:- 8.3.6.4.1: After “Note:” capitalise the beginning of the sentence.

See parts highlighted in blue in the attachment "ERA_solution_for_CR1249_141215.docx".

EECT 09/02/16The Agency informs that as a result of the discussions in the RISC January workshop, it has received a remit to complement the CR1249 solution. This remit requests to provide further information in the DMI, in order to allow safe and comfortable driving operations under reduced adhesion conditions.

EECT 09/03/16The Agency questions how UK and DE intends to use ETCS under low adhesion conditions. They both confirm that they do not intend to flatten the braking curves using the corresponding national values. They consider that this feature of the braking model can probably be used on some specific situations (e.g. high speed lines with defined train types) but that in other context (e.g. on conventional lines with tight timetables), it could lead to unacceptable performance losses since it is impossible to tune them to all possible combinations of adhesion conditions versus type of trains. They consequently prefer to stick to the current practice which is to rely fully on the sole driver’s responsibility. This justifies why the users need supplementary DMI information to help the

driver adjusting his driving style (e.g. braking earlier than the indication limit) to the real time environmental conditions.UK also stresses that it would be inappropriate to indicate on the ETCS DMI the “slippery rail” icon either, because it would give to the driver the wrong impression that the reduced adhesion conditions are taken into account by ETCS while they are not. UK therefore would like to get the supplementary DMI information without having to depress the slippery rail button. DE would agree, since they have internally reached the agreement that forcing the driver to depress the slippery rail button is a “less worse” compromise.

ERA asks why the planning information cannot be used to anticipate the braking phase. The railways consider that it is not conspicuous enough. It requires much more attention mainly due to the logarithmic scale; hence distracting him/her from the other train tasks. The sound is also only triggered when reaching the indication which in such situation is too late (even though the redefinition of the indication time helps).

ERA then questions what additional DMI elements UK and DE have in mind:In DE, according to the national operational rule, the driver usually reduces its speed of 10-30% and needs the target information much earlier than in the nominal conditions (i.e. earlier than when reaching the indication limit). In LZB, the target is permanently displayed. In ETCS B3MR1, the pre-indication was satisfactory even though it did not allow covering all possible adhesion conditions. Displaying the target permanently would be the optimal solution and would allow DE to secure their safety case.For UK, since drivers are also looking outside and undertaking other train management tasks, it is essential that there is an alert zone which triggers a sound when approaching the indication limit in order that the driver can prepare to take actions earlier than under normal conditions. In ETCS B3MR1, the pre-indication was offering such information even though 7sec in rear of the indication running at the MRSP was too short. The optimal solution would be a time to indication which will be triggered around 15sec before reaching the indication limit.

EUG remarks that it is not very clear why UK recommends on one hand to remove the (misleading) adhesion icon and on the other hand, to add a time to indication (TTI) countdown, whose computation reference (the indication) would be clearly wrong since it is deduced from a “non safe” (too permissive) EBD.

ERA also stresses that the TTI seems to address more the UK cab signalling issue (i.e. draw back the driver’s attention onto the DMI while looking outside) rather than the adhesion one. Moreover, a TTI at 15 sec would not cover very poor adhesion conditions. UK answers that it does also cope with the adhesion since it mitigates the risk of braking too late with an acceptable level. The Agency also adds that such pre-indication sound has been exactly one of the disturbances that led to the CR1249. Some railways indeed observe in high density lines useless pre-indication sounds just before the MA renewals. This is however challenged by J.E. Nystad, who explains that the pre-indication was a very useful feature and that

even on high density lines, the associated sound should not be considered as a disturbance for a driver. He also stresses that, together with M. Hodek, this is the position they used to express in the OH WG as representatives of the whole European drivers community, through the ETF and ALE representative organisations.

ERA points out that there are clearly two different DMI approaches and wonders why only one of them cannot be retained (either the target information or the TTI). DE does not need the TTI with its sound alert because they consider that in cab signalling the primary focus should be anyway on looking at the DMI information (even though the driver can look outside at times). For UK, displaying a distance to the target only is not acceptable/sufficient since distance based information is not meaningful to drivers. Useful information needs to be time based (such as the TTI) combined with a sound to draw back the driver’s attention on the DMI. However, DE and UK are not able to agree on only one kind of information, so they prefer a compromise of having both information, which does not hurt each other and that it is the agreed CER position presented in the OH WG end of last year.

ERA 22/03/16See attachment "ERA_solution_proposal_for_CR1249_220316.docx" for a comprehensive solution proposal resulting from the EECT 09/03/16 discussion.This solution proposal allows to discriminate the following user approaches regarding the way the reduced adhesion conditions are handled, through the 3 (train type related) National Values A_NVMAXREDADH:

1) Railways who want to use the ETCS reduced adhesion function, i.e. driver selection or track-to-train profile resulting in a flattening of the braking curves2) Railways who do not want to use the ETCS reduced adhesion function, but who consider the planning info as sufficiently conspicuous for the driver3) Railways who do not want to use the ETCS reduced adhesion function, but who need time based additional DMI information in advance of the Indication4) Railways who do not want to use the ETCS reduced adhesion function, but who need permanent target based additional DMI information

EECT 05/04/16With the exception of an email sent by UNISIG on 01/04/16, no written feedback has been received in advance of the meeting. A round table is therefore performed, starting with the operational experts in order to first validate the concept developed in the ERA proposal before tackling the technical specification details.

UK operational experts:

Mr Levesconte and Lartey express their satisfaction about the way ERA has taken into account their concerns and needs expressed during the previous EECT meeting and in particular the way ERA

proposed to display the “Time to Indication” information. Actually, the display of a stepwise growing square (similar as previously specified by CENELEC for the warning time to intervention) is already greatly appreciated by the Cambrian line drivers.A video showing the display of the TTI square has been prepared by EUG (see attachment “1249_TTI.avi”), in line with the ERA proposal. It is agreed to retain both the proposed fixed value (14s) for the “Time to Indication” and its subdivision into 10 steps.

Further to Mr Lartey’s questions, it is also clarified that the already existing National Value allowing the “slippery rail” driver input to be disabled remains as it is. Should no reduced adhesion ETCS track profile be engineered and the National value for the driver input set to “not permitted”, then the expected UK behaviour (no display at all of the “slippery rail” icon) can be obtained. Depending upon the trackside engineering, it would however also be possible to make appear the “slippery rail” icon together with the TTI display, through e.g. the sending of an ad-hoc track-to-train profile.

DE operational expert:

Mr Eschlbeck only objects that the permanent display of the target information in CSM could have been made not dependent on a National Value but rather be an RU choice, i.e. this permanent target display in CSM could have been used by DE drivers in other member states too.ERA replies that, since the operating rules about driving under reduced adhesion conditions are enforced by the IMs, it is ineluctable at some point that they could only be accommodated by the use of National Values as long as these rules remain national and not harmonised. This fact is acknowledged by all the meeting participants as inevitable.

ERA underlines that although it is indeed very sad to be compelled to reflect that lack of operational harmonisation in the technical system so as to reinforce in the long run the difficulty to drive across borders, the principle of the National Values/IM driven choice is maintained as the less bad solution.Mr Eschlbeck also raises a question about the Sinfo sound played in relation to a change of the displayed target while in CSM: will it be according to a change of speed, distance or both?. It is replied by ERA that the same principle as applicable in TSM has been reused, i.e. if any change of MRDT occurs (in speed or in distance), the Sinfo is played regardless the new MRDT is more or less restrictive than the previous one.

Post meeting note: DB prefers not have the Sinfo when there is a change of the MRDT if the onboard is requested to display the target information in Ceiling Speed MonitoringAs a result, the new section 7.2.6 in the DMI specification will be withdrawn.

FR operational expert:

Mr Dussouchet expresses his satisfaction about the way ERA was able to accommodate the CR1249 to the DB and UK needs while

also keeping possible the display of the original CR1249 solution (which fully matches the SNCF needs).

EUG/UNISIG – technical review of the solution proposal:

Regarding the 6 questions raised by UNISIG:1) The wording of SRS 3.13.2.3.7.7 does not make it clear that the new special values will be applied also when no ETCS slippery rail conditions are ordered.ERA proposes to slightly improve the modification to the first sentence of the clause to read: “In order to adapt to the train behaviour under reduced adhesion conditions, it shall be possible by means of National Values either to limit to a maximum value the speed dependent deceleration for the emergency brake when the reduced adhesion conditions are known to ETCS (see 3.13.2.3.5) or to request supplementary DMI information assisting further the driver in ceiling speed monitoring.”However ERA underlines that this part of the chapter 3.13 is only meant to describe the inputs of the braking model and not to describe how the inputs are processed (see e.g. 3.13.2.3.7.9 which does not tell how and when this speed inaccuracy compensation will be effected). Actually a careful reading of the concerned clauses 3.13.6.2.1.3, together with 3.13.10.3.9&10 leave no room to any misinterpretation.

2) Definition of the variable A_NVMAXREDADHx in its name and description is not in line with its new additional use.No change needed: likewise many other variables which contain special values (e.g. D_TEXTDISPLAY), such special values do not invalidate the name and description. In this particular case, “reduced adhesion conditions” must now be read in the large sense, i.e. it is not to be understood as the ETCS track-to-train packet (which by the way is called “Adhesion Factor” and not “reduced adhesion conditions”) but rather as the real conditions existing on the track.

3) The solution proposal is incompatible because it changes the air gap.This statement is way too simplistic. Actually the only potential incompatibility would come from the very unlikely B3MR1 (or B2 with packet 203) IM choice to pick either the value 61 or 62 to inhibit the flattening of the EB curve, instead of the last possible value 63 (like SBB did). It is therefore agreed to revise in May the BCA analysis for the CR1249 in the light of the amendment of its solution currently performed.

4) If the driver selects low adhesion or if the trackside sends pkt71 and the national value is one of the special values, the adhesion factor is set to slippery but is not taken into account when calculating the braking curves. When the slippery icon is displayed, the driver does not know whether the reduced adhesion has an impact on the braking curves or not.This is only an observation. As underlined by EUG, there are and there will be many other ways to perform bad engineering.

5) SRS 3.18.4.6.1 needs to be updated and maybe other clauses in 3.18.4.6.

It is agreed to replace “shall be” with “is” in the clause 3.18.4.6.1 and to change its classification to “informative” in the chapter 9.

6) Question to the Users: Is it seen problematic that there are the very similar indications with the different meanings in B3R2 and B3MR1: pre-indication (in B3MR1) vs. target information (in B3R2). There might be drivers that will drive B3R2 and B3MR1 trains.The question was also valid with regards to the CR1249 solution adopted in December 2015 (pre-indication vs enhanced planning info) and the current amendment to CR1249 does not change anything to that.

EUG has no comment on the ERA solution proposal 22/03/16 with the exception of the same comment as UNISIG question 1 (verbally shared with ERA when preparing the TTI video). However, on request by Trafikverket, it is agreed to also add the T_driver to the Indication time valid in case the SB feedback is enabled. Justification: the indication formula was modified in the very last EECT Dec 2015 meeting before this B3R2 issuance, with a very few time left to cross check with SB feedback users.

UNISIG 13/04/16In complement to the UNISIG comments already discussed in the April 2016 EECT meeting, UNISIG has the following comments on the CR solution proposal from ERA dated 22/03/2016 («ERA_solution_proposal_for_CR1249_220316.docx»):

1. Assuming that the new additional indications are replacing the pre-indication, we would like to know why the new “indication” functions are not active in the same modes as pre-indication was (e.g. UN mode).2. In the DMI spec part of the solution, the caption for Figure 54a says “Time to Intervention”. This should say “Time to Indication”.3. In the DMI spec part, in 8.2.2.5.3, the term ‘TTI’ referred to in the equation is in our opinion not well defined. It is only implicitly defined in the following SRS requirement: “3.13.10.3.10 If A_MAXREDADH (see 3.13.6.2.1.6) requests a time to Indication as supplementary DMI information, the on-board equipment shall inform the driver as long as the time to travel at the estimated speed the remaining distance to the first Indication location (as specified in 3.13.10.3.8 and 3.13.10.3.8.1) is shorter than a fixed value (refer to A.3.1).” From a formal point of view, this is an explicit requirement to notify the driver as long as the WTTI has been passed, and it only implicitly defines the calculation of the TTI. We think it would be better to separate this into 2 separate requirements; one requirement for defining the conditions for displaying the TTI to the driver, and another to describe how the TTI itself is to be calculated.We therefore propose to modify the clause 3.13.10.3.10 to say: “If A_MAXREDADH (see 3.13.6.2.1.6) requests a time to Indication as supplementary DMI information, the on-board equipment shall compute Time to Indication (TTI) as the time to travel at the estimated speed the remaining distance to the first Indication location (as specified in 3.13.10.3.8 and 3.13.10.3.8.1)”. And add a new sentence in the same clause to say: “The on-board equipment shall inform the driver as long as this time is shorter than a fixed value (refer to A.3.1).”

4. When the on-board behaviour consists in displaying the target in CSM, our understanding is that a juridical data message 20 has to be sent by the ETCS on-board each time D_TARGET changes. This can represent a huge volume of data provided for juridical recording. As a reminder, regarding the message 14 on STM side, a change of D_TARGET has been intentionally excluded from the triggering conditions to send this message. This was done considering that the LZB permanently displays its distance to target, which is also what is done with the proposed complement to CR1249 solution (see new SRS clause 3.13.10.3.9). Such an exclusion could also be considered for the recording of the ETCS data.This could lead to HW changes of JRU to increase the capacity if the triggering condition remains as it is.5. In the part of the solution proposal related to DMI spec, figure 54b is missing.6. In clause 8.2.2.5.5 of the part of the solution proposal related to DMI spec, the wording "e.g. poor weather conditions such as reduced adhesions" should be “e.g. reduced adhesion due to poor weather conditions”. Furthermore, “accurate” is certainly not synonymous with “conspicuous” in the last sentence of the clause and this seems to have no added value. We thus propose to reword the sentence to read: “In those cases, the TTI helps the driver to adapt the driving style accordingly.”7. In clause 8.2.2.5.6 of the part of the solution proposal related to DMI spec, the wording "When the TTI is displayed, the sound Sinfo shall be played." should be "When the TTI starts to be displayed, the sound Sinfo shall be played."

ERA 15/04/16Regarding the questions raised by UNISIG on 13/04/15:1.This assumption is wrong. The new additional indication addresses the fact that 2 member states consider the planning info as not conspicuous enough to fully replace the pre-indication. For DE, the display of the target information has been restored in the way it was specified for the pre-indication but however permanently. For UK, the TTI only materialises a time based pre-indication (instead of a distance based one) but displayed in the same modes as the target speed/distance (i.e. FS/SR/OS). To better emphasise the effect of the toggling function for SR/OS, a new clause 8.2.2.5.6 must be added in the DMI spec part of the solution.2. Agreed3. Agreed4. To be discussed. In our view, this exclusion is questionable because in DE, while in CSM, the only relevant information used by the driver to judge whether to start braking is actually the target distance. With regards to the “huge” volume of data claimed by UNISIG, we note that a full CSM journey (i.e. uninterrupted CSM movement) of 24 hours would lead to the recording of only 8MB due to the sending of message 20 every 0.5s.5. Agreed6. Agreed to change "e.g. poor weather conditions such as reduced adhesions" with “e.g. reduced adhesion due to poor weather conditions”. The 2nd sentence is in our view valuable because it actually justifies why the TTI is presented with squares instead of displaying the actual value of the TTI with digits. However, it is agreed to improve it by removing only the term “conspicuous”.

7. Rejected, see DMI clause 14.3.2.2 which specifies that Sinfo is played once.

In addition, the 2 following editorial modifications are made:- the writing of the formula in clause 8.2.2.5.3 of the DMI spec is slightly improved for the ease of reading.- The planning info of figure 39b is corrected to match the bar graph target distance and to add the B3R2 yellow flag.

See parts highlighted in blue in attachment “ERA_solution_proposal_for_CR1249_150416.docx” reflecting the modifications agreed during the EECT 05/04/16 and the ones resulting from the UNISIG 13/04/16 questions.

ERA 27/04/16The complement of the solution, worked out as a delta from the Dec 2015 recommendation to EC, is now re-integrated in the overall solution with the B3MR1 as a referential.See attachment "ERA_solution_proposal_for_CR1249_270416.docx" for details.In particular:- the 2016 complements in SRS chapter 3 and DMI spec are tagged "CR1249 follow-up"- three editorial findings have been fixed: removal of one former SRS clause 3.13.10.3.10 (before UNISIG review) in excess, reformatting of the DMI table 15 and insertion of a glue sentence in DMI clause 8.2.1.4.3.- the impacts on SRS chapter 9 and on SUBSET-091 have been removed from the attachment, since they have to be addressed by the respective cover CRs (i.e. CR1266 and CR1213)

EUG 04-05-2016In SS-26 A.3.1 the fixed value for the time to display the TTI is called “Warning time to Indication”. In our view calling this a warning time is misleading since it has nothing to do with the real warning time in the braking curve.Proposal: Start time to display the TTI before the first indicationFurthermore, the name of the fixed value is W_TTI. Normally times are starting with “T_” (like previously T_preindication).Proposal: T_ startTTINote: W_TTI is also referenced used in the DMI spec 8.2.2.5.3.In addition we suggest to change the parameter TTI in the DMI spec to T_TTI, to be consistent with the convention for time parameters.

UNISIG 09/05/16With regard to item 4 of ERA reply from 15/04/16 and statement “only 8 MB”: 8 MB per day is potentially a significant amount of data combined with some projects’ requirement of having juridical data stored for 100 days, it means 800 MB of storage capacity.

Regarding the EUG comment posted on 04/05/2016, UNISIG supports the comment in that way that the variable should start with “T_” as some other time variables, e.g. T_TTI. We also propose to rename the variable to say: “Time for determining whether the Time to Indication shall be displayed”.

UNISIG has three additional comments on the solution proposal posted by ERA on 27/04/16:

Regarding modifications of SRS chapter 3:

1. The first equation of 3.13.6.2.1.3 should be valid for locations with normal adhesion conditions AND for locations with reduced adhesion conditions when A_MAXREDADH does not limit to a maximum value the speed dependent deceleration for the emergency brake – not OR as it is in the current proposal.

Regarding modifications of DMI-specification:

2. There have been added rows in tables 8, 9, 10, 11, 13, and 14. The whole rows should appear with revision marks.3. The caption of Table 15a should read “Conditions for display of the Time to Indication” instead of “Conditions for display of the distance to target digital”.

EECT 11/05/16The comments from EUG (04/05/06) and UNISIG (09/05/16) are discussed and the following modifications to the ERA solution proposal 27/04/16 are agreed:

- Regarding the full name of the fixed value: the EUG proposal is retained, however without the term 'start" (reason: this time is not only relevant to start the TTI display but also to stop it in case of braking). The acronym is changed to T_dispTTI - The UNISIG comments 1 and 3 are accepted See parts highlighted in blue in the attachments "SUBSET-026-3 v340_CR1249_110516.docx" and "ERA_ERTMS_015560 v340_CR1249_110516.docx".

Post meeting note: the marks "NA" were missing in the new SRS 4.7.2 row "Time to Indication" and need to be added too.

Regarding the item 4 of the ERA reply from 15/04/16 and the related UNISIG statement 09/05/16: it is agreed that if an user requests such long period of juridical data recording, it will have to bear the consequences in term of storage capacity. Reason: 100 days seems not be a valid requirement for juridical data recording, but rather for diagnosis data recording, which is not the scope of SUBSET-027.The UNISIG comment 2 is also rejected because the reference version for revision marks is 3.4.0 and not 3.5.0.The proposal from EUG/U to use the acronym T_TTI instead of TTI in the DMI 8.2.2.5.3 formula is not retained. Reason: this is not a variable from the airgap but just an acronym introduced in SUBSET-023 and used in different locations in both SRS and DMI.

Supporting document(s) for Justification/Discussion for Solution

ERA_solution_proposal_for_CR1249_010415.docxCR1249_EUG_150414.zipUNISIG_CR1249_COM_SGv1.0.docEUG Actions CR1249.docxUNISIG_CR1249_COM_SGv1.0_EECT120515.docxERA_solution_proposal_for_CR1249_270515.docxOptions for speed indication in planning area.docxCR1249 BDK input.docx

ERA_solution_proposal_for_CR1249_070915.docx15E116-1_Validation_report_CR1249_bundle.docxCR1249 - ERA_ERTMS_015560 part - U.docxCR1249 - ERA_ERTMS_015560 part_EECT071015.docxValidation_report_CR1249_bundle_EECT081215.docxERA_solution_for_CR1249_141215.docxERA_solution_proposal_for_CR1249_220316.docx1249_TTI.aviERA_solution_proposal_for_CR1249_150416.docxERA_solution_proposal_for_CR1249_270416.docxSUBSET-026-3 v340_CR1249_110516.docxERA_ERTMS_015560 v340_CR1249_110516.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

EEIG (ERTMS users group)

Contact person name R. DijkmanContact Person e-mail adress rdijkman@ertms.beEndorsed by Recognised Organisation(s)Project Information The problem was detected when simulations were made to analyse

if the performance requirements could be met by ERTMS on the high speed line between Paris and Lyon.

Submitter Reference Number EEIG435List of assigned WG(s)Severity Performances impact, non interoperability and non safety relatedTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs 1026

1272

Date of Submission 2014-09-18 01:11:04 PMLast modification date 2016-05-13 02:41:56 PM

Identification number 1250State Presented_to_ECHeadline Incorrect description in gradient profileImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-026 V340Error/Enhancement ErrorProblem/Need description 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 descriptionSolution Proposal by submitter For 7.4.2.6:

Delete the sentences. ”D_GRADIENT gives the distance to the next change of the gradient value. The gradient value is the minimum gradient for the given distance.”Note: Both sentences can simply be deleted because there is no reason to repeat the definitions which are given in the variable description.

For 7.5.1.37:In the description modify "minimum" to "engineered".

Supporting document(s) for solution proposalAgreed 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 solutionJustification/Discussion for Solution

UNISIG 20/11/14The solution proposal by submitter is agreed.

EECT 03/12/14The following has been left over in the solution proposal by submitter: the name of the variable (“safe gradient”) has not been cleaned up accordingly => the solution amended with the term “safe” deleted is agreed.

Supporting document(s) for Justification/Discussion for SolutionPreliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment Benefits

Economic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

EEIG (ERTMS users group)

Contact person name R. DijkmanContact Person e-mail adress rdijkman@ertms.beEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number EEIG436List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2014-09-18 01:20:49 PMLast modification date 2016-01-06 04:11:02 PM

Identification number 1254State Presented_to_ECHeadline Session establishment attempts to report mode changeImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-026 v3.4.0Error/Enhancement ErrorProblem/Need description SRS 3.5.3.4 c) requires that the ETCS on-board equipment

establishes a communication session to report a mode change that is not considered as an End of Mission to the RBC. This includes transitions from SL to SB, PS to SB, SH to SB etc.

There is no restriction regarding the number of attempts to establish a session with the RBC for reporting such a mode change, and the conditions in 3.5.3.7 for stopping the attempts of session establishment may never be met. This means the on-board equipment will continuously attemptto establish a session for reporting the mode change. This can lead to operational deadlocks.

For example, when changing from SL to SB, the on-board will immediately attempt to establish a communication session to report the mode change. If this is not successful then the on-board will continue to try to establish the communication session. When the driver subsequently opens the desk, the SoM cannot commence because a communication session is being established (see SRS 5.4.3.2 step S0). Furthermore, according to the DMI specification, no options are available on the DMI (“Main window with all buttons disabled. The hour glass symbol ST05 is displayed”). Closing the desk will not stop the attempts to establish the session either, so the only way for the driver to resolve the deadlock would be to go to NP

mode. Even if the establishment of the session is successful in the case described above, the SoM procedure still cannot commence until the RBC orders the termination of the communication session (see SRS 5.4.3.2 step S0). If the RBC does not terminate the session, then once again a deadlock arises, which cannot be resolved by closing the desk.

Supporting document(s) for problem/need descriptionSolution Proposal by submitterSupporting document(s) for solution proposalAgreed Solution Modify SUBSET-026 v3.4.0 as follows:

Modify clause 3.5.3.4 c) as follows:Replace “not considered as an End of Mission” with “neither considered as an End of Mission nor triggered from condition g) below”.Modify clause 3.5.3.7 a) as follows:Replace “If this request is part of an on-going Start of Mission procedure” with “If this request is part of an on-going Start of Mission procedure or is related to the establishment of a communication session due to condition 3.5.3.4 c)”Replace “If this request is not part of an on-going Start of Mission procedure” with “If this request is not part of an on-going Start of Mission procedure and is not related to the establishment of a communication session due to condition 3.5.3.4 c)”

Supporting document(s) for agreed solutionJustification/Discussion for Solution

UNISIG 28/05/15See attachment "Solution proposal for CR1254 20150528" for a solution proposal.

EUG 02/06/151. We believe that the item 2 (the operational deadlocks during the SoM) is not solved by the note in S0. The RBC cannot know the status of the communication session on the on-board in every case (maybe the establishment is on-going by the on-board, but this is not yet known by the RBC). A solution should be found in the on-board (which knows when the communication is being established and where the SoM takes place).2. In addition the changes in 3.5.3.4.c are not clear, specially after reading the note. Could you clarify the aim of the change? We are not sure if we understand it correctly.

ERA 03/06/15Regarding item 2, we consider that the note in step S0 is superfluous and that anyway this item should be rejected.We also share the EUG understanding issue about the change to 3.5.3.4 c), we therefore propose to slightly rephrase the modifications to the clauses 3.5.3.4 c) and 3.5.3.7 a), see attachment "Solution proposal for CR1254_revERA.docx" for details.

EECT 10/06/15

Regarding item 2, UNISIG thinks that a mechanism needs anyway to be specified to avoid a possible deadlock if for instance the session termination from the RBC is lost following the mode change report.ERA reminds that a similar CR (CR 968) was already discussed during the triage 2014, reclassified as enhancement and finally postponed. It could be much wiser to put the effort improving the communication system (if needed) rather than over-specifying the behaviour for such “rare” occurrences (see reason for postponement of CR968). This is therefore the justification why item 2 should be rejected.

EUG 01-07-2015In addition to the ERA solution (on which we have no detailed comments) we think it would be good to stop the attempts anyway when closing/reopening the desk.We have one clarification question. Why is this issue only solved for the situation in 3.5.3.4c and not for instance for 3.5.3.4d or e?

UNISIG 07/07/15ERA solution proposal posted for item 1 on 03/06/15 is agreed.

EECT 08/07/15Regarding the two EUG suggestions/questions (01/07/15):The first suggestion is superfluous because all the desk closure situations will be covered for what regards the attempts to establish a session: - within SoM (post meeting note: see new clause 3.5.3.9.1 a) as per CR1117) - outside SoM when there is mission (post meeting note: see new clause 3.5.3.9.1 b) as per CR1117) - outside SoM when there is no mission the mode change reporting and the defined number of attempts as introduced by this CR will apply.

For the second question, ERA recalls that it is EUG, in the frame of CR764, which requested to have the attempts to set-up the a safe connection continued as long as the train stands inside an area where level 2 is implemented (i.e. there is a radio coverage). Since 3.5.3.4d) and e) do correspond to such situation, any attempts should be continued as well.However in spite of the justification given by ERA (10/06/15), UNISIG still does not agree with the item 2 rejection.The CR is closed with the amended solution proposal 03/06/15 (i.e. with only the item 1 fully agreed by EUG/U) and without item 2 (ERA decision).

Supporting document(s) for Justification/Discussion for Solution

Solution proposal for CR1254 20150528.docxSolution proposal for CR1254_revERA.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for

Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name P. PrieelsContact Person e-mail adress philippe.prieels@transport.alstom.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number List of assigned WG(s)Severity Interoperability and non safety relatedTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2014-10-24 01:58:47 PMLast modification date 2016-01-06 04:11:02 PM

Identification number 1255State Presented_to_ECHeadline Impossibility to transmit unknown values in the message “Additional

data”Impacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-027Error/Enhancement ErrorProblem/Need description 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 (on-board not fitted with Mobile Terminals i.e. not capable to operate in level 2/3) and this message does not allow to express that.

Supporting document(s) for problem/need descriptionSolution Proposal by submitterSupporting document(s) for

solution proposalAgreed Solution Modify SUBSET-027 v3.1.0 as described in the attachment

"ERA_solution_for_CR1255_191015.docx"Supporting document(s) for agreed solution

ERA_solution_for_CR1255_191015.docx

Justification/Discussion for Solution

ERA 24/02/15See detailed solution proposal in the attachment "ERA_Solution_proposal_for_CR1255_240215.docx"

UNISIG 27/02/15Solution proposal posted by ERA on 24/02/15 is agreed.

EUG 03-03-2015Agreed

ERA 19/10/15Due to CR1087, the solution proposal 24/02/15 needs to be amended. See parts highlighted in blue in attachment "ERA_solution_proposal_for_CR1255_191015.docx".

UNISIG 23/10/15The updated solution proposal posted by ERA on 19/10/15 is agreed.

EUG 29-10-2015Agreed.

Supporting document(s) for Justification/Discussion for Solution

ERA_Solution_proposal_for_CR1255_240215.docxERA_solution_proposal_for_CR1255_191015.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name P. PrieelsContact Person e-mail adress philippe.prieels@transport.alstom.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2014-11-10 04:23:07 PM

Last modification date 2016-01-06 04:11:03 PM

Identification number 1260State Presented_to_ECHeadline Inconsistent set of clauses regarding the service brake interface in

SH modeImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-026Error/Enhancement ErrorProblem/Need description 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.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 descriptionSolution Proposal by submitterSupporting document(s) for solution proposalAgreed Solution 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"

Supporting document(s) for agreed solution

ERA_Solution_for_CR1260_090315.docx

Justification/Discussion for Solution

ERA 24/02/15It is proposed, in line with the analysis of the different items of Train Data carried out in the frame of the CR239, to exclude from the Train Data the traction/brake parameters which obviously can never be affected by the Train Data acquisition, i.e. in other terms those configuration items which are considered as invariant whatever the composition of the train is.In addition it is confirmed that the special brakes statuses are not to be considered as Train Data either, because it is a fact that they can be affected by the track conditions "Inhibition of special brakes" and that if they would be considered as Train Data, this would not comply with clause 3.18.3.1.

See attachment "ERA_Solution_proposal_for_CR1260_240215.docx" for details.

Note: according to the above, the CR239 will have to be reopened.

UNISIG 27/02/15Solution proposal posted by ERA on 24/02/15 is agreed.Note: a slight modification modification to ERA posting text is proposed : replace "the traction/brake parameters" with "those traction/brake parameters" to make clear that only a part of the traction/brake parameters can never be affected by the Train Data acquisition.

EUG 03-03-2015One editorial comment to the ERA proposal. The sentence in 3.13.2.2.1.2 is not easy to read because it contains 3x the word "except". We propose to use the word "except" only once and let it be followed by 3 bullet points with the details on the 3 types of exceptions.In addition we also support the UNISIG remark.

EECT 09/03/15The ERA solution proposal 24/02/15 is agreed, with the editorial amendment as proposed by EUG (03/03/15).

Supporting document(s) for Justification/Discussion for Solution

ERA_Solution_proposal_for_CR1260_240215.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name P. PrieelsContact Person e-mail adress philippe.prieels@transport.alstom.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number List of assigned WG(s)Severity Performances impact, non interoperability and non safety relatedTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2014-11-10 04:42:59 PMLast modification date 2016-01-06 04:11:03 PM

Identification number 1262State Presented_to_ECHeadline Issues related to the initiation of a communication session by an

RBCImpacted System ETCS&GSM-RReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-026Error/Enhancement ErrorProblem/Need description There are several ambiguities related to the acceptation of a

communication session initiated by RBC:- There is no clear statement in which conditions the RBC shall initiate the communication session. The situations, in which this could be worth, if existing, seem very limited, especially since the change brought by CR 764. The ERTMS/ETCS on-board indeed permanently attempts to establish a communication session with the RBC during a mission in level 2 or 3.- Shall an "Initiation of a communication session" message be accepted by an ERTMS/ETCS on-board that has already sent its own "Initiation of a communication session" message (messages crossing each other)?- What shall happen to a communication session already on-going when the ERTMS/ETCS on-board receives the "Initiation of a communication session" message?- Shall an RBC that initiates a communication session always be considered as supervising?- At loss of a safe radio connection that has been initiated by the RBC, shall the ERTMS/ETCS on-board try to re-establish it (SRS clause 3.5.4.2)?- At message reception time-out (T_NVCONTACT), shall the ERTMS/ETCS on-board “reset” a safe radio connection that has been initiated by the RBC (SRS clause 3.16.3.4.3)?- When the train exits a radio hole, shall the ERTMS/ETCS on-board try to re-establish a communication session that has been initiated by the RBC (SRS clause 3.5.3.4 e)?- Regarding the 3 last items above, how could the ERTMS/ETCS on-board know the RBC phone number (needed to establish a safe radio connection)?

In addition, if a communication session has been initiated by the RBC, then the RBC System Version (Msg 32) is not transmitted by the RBC during the establishment of the session. From 3.5.3.12, “Note: In the case the RBC is the initiator, there is no need to verify the compatibility of the system versions and for the on-board to send its telephone numbers, because the on-board is obviously already known to the RBC.”The B3 onboard supports more than one system version, and the B3 onboard needs to know which system version to use when communicating with this RBC. This is needed not only for determining the version of the language to be used (X=1 or X=2), but also for determining the operated system version.According to Chapter 4, the onboard stores the RBC System Version and deletes it only upon entering NP. So, if an RBC were to initiate a communication session with a B3 onboard, there would be a couple of possibilities:

1. The onboard may have no RBC System Version stored and no RBC System Version will be received from the RBC. In this case it will not be possible for the onboard to determine which version of the language to apply (X=1 or X=2), nor will it be able to determine the operated system version. It is not clear whether 3.17.2.9.1 would apply in this case.2. The onboard may have a stored RBC System Version from a previous session. An onboard could therefore use this RBC System Version that has been stored from a previous session, possibly with a different RBC, to determine the system version to be applied with the current RBC.In either case, there is a possibility that a B3 onboard would operate the wrong system version when an RBC initiates a communication session.

Supporting document(s) for problem/need descriptionSolution Proposal by submitterSupporting document(s) for solution proposalAgreed Solution Modify SUBSET-026 v3.4.0, SUBSET-037 v3.1.0, EIRENE FRS

v7.4.0, EIRENE SRS v15.4.0 and A11T6001 v12.4 as described in the attachment "CR 1262_solution_consolidated.docx"

Supporting document(s) for agreed solution

CR 1262_solution_consolidated.docx

Justification/Discussion for Solution

UNISIG 04/05/15See attachment "CR 1262 Solution proposal v06.docx" for a solution proposal that removes the possibility for an RBC to initiate a communication session with the on-board. This solution is based on the assumption that RBC initiated calls will already be prevented at the “telecommunication layer level”. The details of this need to be further elaborated.

EUG 06-05-2015We have 2 remarks on the UNISIG proposal.1) What is behind the yellow sentence related to 7.5.1.154? Who do you expect to confirm this?2) Why do you propose to modify 8.6.17? We thought that with this CR we intend to delete the possibility for the trackside to call the onboard. Why then do we send the phone numbers to the trackside? Please clarify.

EECT 13/05/15The UNISIG solution proposal 04/05/15 is missing the (important) part dedicated to the communication layer related documents and also contains on open question, see EUG remark 1 (06/05/15).Regarding this open question it is clarified that the value UNKNOWN for T_TRAIN should be kept as this is allowed by the current specifications. As stipulated 3.16.3.1.4, the requirements for time stamping in 3.16.3.2 do not apply to high priority messages.

Regarding the EUG remark 2 (06/05/15), it is clarified that the on-board telephone numbers shall not be kept as mandatory packet since the corresponding function disappears with this CR. Therefore, the necessary provisions in chapter 6 shall be specified when the on-board sends a "session established" message to an RBC with a system version lower than or equal to 2.0.

UNISIG 28/05/15See attachment "CR 1262 Solution proposal v07.docx" for a solution proposal based on remarks and conclusions of EECT 13/05/15. According to ERA's information received by mail on 26/05/15 that chapter 6 part of this CR1262 should be superseded by the CR299 solution proposal, this solution proposal does not contain the chapter 6 aspects related to removal of the on-board telephone numbers.

EUG 02/06/151. DB input indicated that their ETCS implementation projects that will start in 2015 (supplied by Siemens), already forsee the use of the initiation of the communication session by the RBC. Therefore the current solution proposal is not acceptable.The Scenario where it is implemented it is as follows and aims at optimising radio capacity:The functionality is used when a faster train has to overtake a slower one train. The slower train is moved aside, stopped, and the radio connection finalised by trackside (to release the radio channel). Only when the 'faster' train has exit the area, the RBC contacts back the 'slower' train in order to allow it to continue running. The RBC would be able to manage the radio capacity available establishing and terminating the communication session with the different trains depending on the radio capacity and the information he received from other trackside systems. The list of issues pointed out by the problem description will apparently not apply to this scenario, where the first time it is the on-board who contacts the RBC. It is during the running, when the RBC knows the trains in the area that the scenario will occur. 2. In addition some railways see that the possibility to initiate a comunication session could be useful in some scenarios. In the case of train driving on a pure L2 area, where the driver selects unduly Level 0, this functionality could allow the RBC to contact the train, establish the session and send again a transition order to L2.

ERA 03/06/15Regarding the SUBSET-026 part of the attachment "CR 1262 Solution proposal v07.docx", we have only a few editorial remarks (see parts highlighted in blue in attachment "CR 1262 Solution proposal v07_revERA.docx" and undue revision marks removed in 8.6.17).Regarding the modifications to A11T6001 v12.4, the proposal will be checked by the GSM-R related WGs. In addition the necessary modifications to the EIRENE FRS and SRS will have to be identified too.

Regarding the EUG statement 02/06/15:Even though the scenario foreseen by DB would not suffer from the shortcomings identified in the CR problem description, we consider that the interoperability of this function is far from being granted.Therefore to fix a not interoperable function which will anyway disappear with the CS radio bearer is in our opinion not the right way forward.

ERA 17/06/15See attachment "CR1262_EIRENEA11_ERA170615.docx" for the

proposed modifications to EIRENE FRS & SRS and the FFFIS Euroradio.

EECT 09/09/15The DB main concern is the compatibility because they have B3 MR1 lines that will enter into service in December 2015. If the current solution proposal is retained a call by the RBC to a B3R2 train could not be successful, which means that the CR1262 would be incompatible.It is again wondered how this functionality could have been properly implemented, considering the severe shortcomings pointed out by UNISIG in the problem description. In particular UNISIG recalls the shortcoming about the operated system version which could be unknown to the on-board when it is called back by the RBC. EUG argues that the suppliers involved in the concerned project have ensured that the functionality will work properly, in spite of the reservations listed in the CR.Considering this deadlock situation, it is asked to the telecom experts to clarify what could happen in case a train in PS would be called in CS by an RBC. This situation unfortunately could arise even on the lines operated in CS but where PS service (not used by ETCS) is provided: when the train is parked, waiting to be called back by the RBC, the on-board might launch the periodic check of keys and contact its home KMC with a MT used in PS mode. Then after this particular MT could be called in CS by the RBC while it is still in session with the home KMC.According to the telecom experts this situation is not currently specified and it is unlikely to be handled due to fact that there is only one serial connection to the MT. It is however not possible to draw a conclusion during the meeting and this matter has to be further investigated.

EECT 06/10/15The outcome of the UNISIG investigation (see attachment "Action 13.09.msg") on what could happen in case a train in PS would be called in CS by an RBC is discussed. It shows that it is far from being granted that a MT of a B3R2 train could properly process a trackside originated CS call.Considering that EUG could not table any detailed evidence on how the function implemented in the DB project really works and that the list of shortcomings brought in by UNISIG remains as it is, ERA decides that the functionality for the incoming calls from RBC to OBU will be removed for the B3 R2. It is also recalled that like for other outstanding open points in B2, backward compatibility with not interoperable/bugged functionality can by definition not be sought. The DB implementation will therefore remain a national function, which will not even be interoperable with B2 on-boards other than those ones equipped by the two concerned suppliers.Concerning the GSM-R part of the CR, no feedback from UIC was received prior to the meeting on the modifications for EIRENE FRS and SRS proposed by ERA in June 2015. The UIC input received during the meeting (see attachment "CR1262 Solution proposal ERA-UIC 080915.docx") will be analysed by ERA and the CR will be closed unilaterally by ERA, without consolidated position either from EUG or from UNISIG.Moreover, ERA recalls the recommendation mentioned in the

September EECT meeting, consisting in preventing call from RBCs (or from any calling entity) from reaching the MT, through the network subscriber profile.

ERA 19/10/15See attachment "CR1262 Solution_GSM-Rpart_191015.docx" for the final batch of modifications necessary to the EIRENE FRS & SRS and to FFFIS Euroradio.

Supporting document(s) for Justification/Discussion for Solution

CR 1262 Solution proposal v06.docxCR 1262 Solution proposal v07.docxCR 1262 Solution proposal v07_revERA.docxCR1262_EIRENEA11_ERA170615.docxAction 13.09.msgCR1262 Solution proposal ERA-UIC 080915.docxCR1262 Solution_GSM-Rpart_191015.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name P. PrieelsContact Person e-mail adress philippe.prieels@transport.alstom.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2 & GSM-R B1Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2014-11-10 05:01:34 PMLast modification date 2016-01-06 04:13:58 PM

Identification number 1265State Presented_to_ECHeadline Miscellaneous editorial findings in B3 MR1Impacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-026 v3.4.0, SUBSET-027 v3.1.0, SUBSET-034 v3.1.0Error/Enhancement ErrorProblem/Need description See attachment "Misc_editorial_findings_in_B3MR1_v1.xlsx"Supporting document(s) for problem/need description

Misc_editorial_findings_in_B3MR1_v1.xlsx

Solution Proposal by submitter See attachment "Misc_editorial_findings_in_B3MR1_v1.xlsx" (columns D & E) in the field "Problem/Need description".

Supporting document(s) for solution proposalAgreed Solution Modify SUBSET-026 v3.4.0, ERA_ERTMS_015560 v3.4.0,

SUBSET-027 v3.1.0, SUBSET-034 v3.1.0, SUBSET-035 v3.1.0, SUBSET-036 v3.0.0, SUBSET-037 v3.1.0, SUBSET-039 v3.1.0, SUBSET-091 v3.3.0 as described in the attachment "Solution_for_CR1265_161215.xlsx"

Supporting document(s) for agreed solution

Solution_for_CR1265_161215.xlsx

Justification/Discussion for Solution

ERA 18/03/15See updated attachment "Misc_editorial_findings_in_B3MR1_v2.xlsx" (new items are highlighted in yellow), further to various inputs received.

EUG 07-04-2015See our response to ERA proposal 18/03/15 in attachment "Misc_editorial_findings_in_B3MR1_v2-1_EUG".

UNISIG 08/04/15See attachment "Misc_editorial_findings_in_B3MR1_v2-SG.xlsx" for UNISIG comments on ERA solution proposal posted on 18/03/15.Note: attachment "Misc_editorial_findings_in_B3MR1_v2-SG.xlsx" also contains comments on items that were already present in file "Misc_editorial_findings_in_B3MR1_v1.xlsx".

ERA 30/04/15See attachment "Misc_editorial_findings_in_B3MR1_v3.xlsx" for replies to the UNISIG and EUG comments, together with new items added (highlighted in yellow) as per UNISIG and ERA latest inputs.Note: some of the comments from UNISIG (08/04/15) and EUG (07/04//15) were raised against the problem formulation of the item themselves. They have been removed and the corresponding cells (highlighted in blue) fixed accordingly.

EUG 07/05/2015See attachment "Misc_editorial_findings_in_B3MR1_v3_EUG.xlsx" for the EUG answers to the updated table of editorial findings.

UNISIG 11/05/15See attachment "Misc_editorial_findings_in_B3MR1_v3_EUG_U.xlsx" for UNISIG comments on file "Misc_editorial_findings_in_B3MR1_v3.xlsx" posted by ERA on 30/04/15.

EECT 09/07/15The items marked as “D” are reviewed, see cells highlighted in blue in the attachment "Misc_editorial_findings_in_B3MR1_v4.xlsx" for resulting modifications. In addition the few cells marked as A2 are changed to A1, since the last release (MR1) was published in the Official Journal and therefore all the changes must be marked with this CR1265.With regards to the following specific points:- S26 line 17: it is agreed to make the reporting of data consistency error also active in SL mode. Justification given by UNISIG: there

can be trains with the leading engine not fitted with ETCS and only the SL engine(s) able to report such data consistency error- S36 line 2 (CR977): in spite of the UNISIG disagreement to remove the note in the SUBSET-036, it is strongly recalled by ERA that there cannot be in the ETCS specifications any provision that could make the installation of any balise dependent of the full on-board processing time of a balise message, as purposely clarified by the CR977.With the exception of the pending discussion for S36 line 2, all the decisions and solutions in the attachment "Misc_editorial_findings_in_B3MR1_v4.xlsx" are agreed.

UNISIG 18/08/15Further to the discussion for S36 line 2 (09/07/15), UNISIG agrees with the removal of the note [8] from the SUBSET-036”

ERA 24/08/15See attachment "Misc_editorial_findings_in_B3MR1_v5.xlsx", which includes the UNISIG agreement on S36 line 2 and a batch of new items highlighted in yellow.

UNISIG 01/09/15See attachment "Misc_editorial_findings_in_B3MR1_v5_U.xlsx" for the UNISIG review of the new items per entry ERA 24/08/15.

EECT 08/09/15The UNISIG comments (01/09/15) on the new entries are addressed, see lines highlighted in yellow in the attachment "Misc_editorial_findings_in_B3MR1_v5_EECT.xlsx".Although they did not raise any comment on the new entries, EUG agrees with all the corresponding decisions reached during the meeting.

ERA 22/10/15See attachment "Misc_editorial_findings_in_B3MR1_v6.xlsx", which includes a batch of new items highlighted in yellow

UNISIG 30/10/15The new items of file "Misc_editorial_findings_in_B3MR1_v6.xlsx" posted by ERA on 22/10/15 are agreed.

EECT 03/11/15New items are added due to feedback from the Test Spec WG and on request by UNISIG. All these new items are discussed and agreed.See rows highlighted in yellow in the attachment "Misc_editorial_findings_B3MR1_v7_EECT031115.xlsx".Post meeting note: in line #31 of the sheet “S26”, the section number has been corrected from 6.3.1.3 to 6.3.1.2.

EECT 08/12/15In the frame of the overall CR consolidation phase and of the implementation of the CRs into the B3R2 documents, new items and updates of existing ones are agreed.See tags "CR1265 to be amended accordingly" in the attachments "B3R2_ERAdocs_consolidated review sheet_final.docx" &

"B3R2_Udocs-consolidated review sheet_final.docx" and the cells highlighted in blue in the attachment "Misc_editorial_findings_B3MR1_v8.xlsx".

Supporting document(s) for Justification/Discussion for Solution

Misc_editorial_findings_in_B3MR1_v2.xlsxMisc_editorial_findings_in_B3MR1_v2-1_EUG.xlsxMisc_editorial_findings_in_B3MR1_v2-SG.xlsxMisc_editorial_findings_in_B3MR1_v3.xlsxMisc_editorial_findings_in_B3MR1_v3_EUG.xlsxMisc_editorial_findings_in_B3MR1_v3_EUG_U.xlsxMisc_editorial_findings_in_B3MR1_v4.xlsxMisc_editorial_findings_in_B3MR1_v5.xlsxMisc_editorial_findings_in_B3MR1_v5_U.xlsxMisc_editorial_findings_in_B3MR1_v5_EECT.xlsxMisc_editorial_findings_in_B3MR1_v6.xlsxMisc_editorial_findings_B3MR1_v7_EECT031115.xlsxB3R2_ERAdocs_consolidated review sheet_final.docxB3R2_Udocs-consolidated review sheet_final.docxMisc_editorial_findings_B3MR1_v8.xlsx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

ERA (European Railway Agency)

Contact person name A. HougardyContact Person e-mail adress alain.hougardy@era.europa.euEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2014-11-27 08:10:53 PMLast modification date 2016-01-06 04:11:03 PM

Identification number 1266State Presented_to_ECHeadline Classification of SRS clausesImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-026 v3.4.0Error/Enhancement ErrorProblem/Need description In order to be able to assess properly the compliance of an ETCS

onboard with the SUBSET-026, it is necessary to comprehensively establish which are the clauses that consist of requirements allocated to the ETCS onboard and conversely which are the clauses that do not, either because they are requirements allocated to the ETCS trackside only or because they are of another type.For instance it is obvious that today the clause 1.7.1.2 ("The ERTMS/ETCS on-board equipment shall implement all mandatory requirements, with the only exceptions and conditions explicitly stated in the Control-Command and Signalling TSI and in this SRS") cannot be fully met, since some of the SRS clauses including the term "shall" are relevant to the ETCS trackside only.Moreover some clauses are unduly using the term "shall" because their compliance cannot be tested as such.

See attachment "Classification_SRS_clauses_v1.xlsx" for the detailed asessment.

Supporting document(s) for problem/need description

Classification_SRS_clauses_v1.xlsx

Solution Proposal by submitter The classification of all the SRS clauses should be part of SRS itself, preferably forming an ad-hoc appendix in each of the eight SRS chapters.In addition, the term "shall" should be removed from the clauses that are identified as not being requirements allocated to ETC onboard and/or trackside.

Supporting document(s) for solution proposalAgreed Solution Modify SUBSET-026 v3.4.0 as follows:

Modify chapters 1 to 8 as described in the attachments "Solution_for_CR1266-ch1to8.xlsx" and "SUBSET-026-1_CR1266_081215.docx"Add new chapter 9 as per attachment "SUBSET-026-9 v351.doc"

Supporting document(s) for agreed solution

Solution_for_CR1266-ch1to8.xlsxSUBSET-026-1_CR1266_081215.docxSUBSET-026-9 v351.doc

Justification/Discussion for Solution

UNISIG 27/02/15See column H "Review comments" in sheets "Chapter 3" and "Chapter 4" of attachment "Classification_SRS_clauses_v1_SG 20150227.xlsx" for SG comments on classification of clauses of Chapter 3 and Chapter 4.

EUG 05-03-2015See columns H to M in the attachment "Classification_SRS_clauses_v1_EUG_20150304". The column H indicates if the classification is OK (a) or a clarification needs to be discussed (c).There are some general concerns in EUG about the purpose and possible unwanted side effects of the classification. See attachment "SRS classification summary EUG 20150304" for some points which are mainly intended to trigger a discussion with ERA and UNISIG in the EECT meeting.

EECT 09/03/15The EUG general concerns (05/03/15) are addressed, see

attachment "SRS classification summary EECT_090315.docx".

ERA 06/05/15See consolidated replies to the UNISIG and EUG comments for chapters 3 and 4 in attachment "Classification_SRS_clauses_v2.xlsx". The modified cells in columns A to F are highlighted in yellow.

UNISIG 30/06/15See file "Classification_SRS_clauses_v2-U.xlsx" for UNISIG comments on the classification of clauses of chapters 1, 2, 5, 6, 7 and 8.

EECT 08/07/15The items marked as “D” for chapter 3&4 are reviewed, see cells highlighted in blue in the attachment "Classification_SRS_clauses_v3_EECT080715.xlsx" for resulting modifications. In particular, ERA explains that the wording "it shall be possible" in the SRS is used to reflect the optional character of the trackside functions (see also clause 1.7.1.3).With regards to the following specific points:- chapter 3 line1926: although the principle that a missing requirement needs to be added is already agreed by UNISIG/EUG, the item tab still needs a solution proposal.- chapter 4 line 1069: it is proposed not to individualize the table rows anymore, since all the tables are mandatory in full. The Excel sheet itself (and the resulting table in the SRS) needs to be cleaned up.The review of the other chapters will be performed in the next meeting. Regarding the chapters 3&4, UNISIG stresses that there are still items marked as “A” or “R” they want to discuss during the next meeting as well.EUG also recalls that the introduction of a specific section in chapter 1 should be brought in by this CR.ERA also points out that the attachment "Classification_SRS_clauses_v3_EECT080715.xlsx" already contains an ERA review of the consolidated EUG and UNISIG comments for chapters 1, 2, 5 & 6

ERA 26/08/15See attachment "CR1266_otherSRSmods.zip" for the proposed modifications to SRS chapter 1. Instead of an annex in each SRS chapter, it is also proposed to create a new SRS chapter 9 titled "Classification of clauses". This will allow a much easier maintenance of the document, e.g. in case new annexes containing requirements are created later in the existing chapters.

UNISIG 01/09/15See the attachment “CR1266_otherSRSmods_SG20150901” for the UNISIG comments on the modifications to SRS chapter 1 and SRS chapter 9.

EUG 02-09-2015We support the UNISIG comments. The question about "optional requirements" should be discussed in the EECT.Attachment "SUBSET-026-9 v342_SG20150901-EUG" contains an

additional comment from EUG on top of the UNISIG comments.

ERA 02/09/15See attachment "Classification_SRS_clauses_v4.xlsx" for an updated version of the classification of clauses.This includes: - the resolution of the two open specific points identified in the last EECT meeting 08/07/15 (chapter 3 line1926 and chapter 4 line 1069). The concerned cells/rows are highlighted in blue. - the ERA replies to UNISIG/EUG comments for chapters 7 and 8 - a new list of items (non empty cells in columns "second ERA review"), resulting from a cross check of a past review round between ERA and the Test Spec WG. The cells coloured in red identify those ones whose content is proposed to be changed further to this second ERA review.

Note: the highlighting in yellow of some cells is not meant to identifiy the delta between versions of the file, but rather to permanently identify the modifications due to agreed review comments, otherwise these latter would not be readable anymore.

EECT 08/09/15The UNISIG/EUG comments on the ERA solution proposal for SRS chapters 1 & 9 (26/08/15) are discussed, see replies tagged “EECT080915” in the Word comments inside the attachments "SUBSET-026-1_CR1266_EECT080915.docx" and "SUBSET-026-9 v342_EECT080915.docx".

EUG expressed their concerns on the classification, they have got bad experiences about suppliers justifying non compliances based on requirements they consider that they do not apply to its product. This CR could provide further justification to this supplier behaviour.UNISIG replies that the suppliers shall use all the clauses of the SRS for the design, the CR is about proving the compliance with the SRS not about selecting a group of clauses from the SRS to design a product.

Regarding the Excel file itself (see attachment "Classification_SRS_clauses_v4_EECT080915.xlsx"): - The ERA solution proposals resulting from EECT meeting 08/07/15 are agreed, however with a slight amendment proposed by UNISIG for the rephrasing of the clause 3.16.3.4.1.3 (ch3 line 1896) - On request by UNISIG, the decision “R” for Ch 8 line 23 is revoked, because a clarification is deemed necessary for the multiple instances of packets in train-to-track messages EUG 01-10-2015EECT Action 13.11: We agree with the rows with non empty cells in the column “ERA 2nd review” in the document "Classification_SRS_clauses_v4".

UNISIG 02/10/15See non-empty cells in column titled “U 22/10/15” of the sheets “Chapter2” to “Chapter8” of attachment “Classification_SRS_clauses_v4-U.xlsx” for:• UNISIG opinion on points from ERA 2nd review round marked as

“D” • Remaining UNISIG comments on ERA replies to UNISIG commentsNote: sheet “Chapter 1” does not contain any column titled “U 22/10/15” because this sheet does not contain any item from ERA 2nd review and U does not have any remaining comments on ERA replies to its comments for chapter 1.

In addition to the comments in attachment “Classification_SRS_clauses_v4-U.xlsx”, UNISIG proposes to add a clause 9.3.2.3 in new SRS chapter 9 to read “When a clause contains an on-board or trackside requirement but also an informative part or a definition, the clause is classified as a requirement”. The aim of this proposal is to make clear the principle that has been followed for the classification of these clauses.

EECT 08/10/15The proposal from UNISIG (02/10/15) to add a new clause in SRS chapter 9 is refined as follows: “When a clause contains an on-board and/or trackside requirement but also an informative part and/or a definition, the clause is classified as a requirement”. However EUG cannot yet agree during the meeting and would like to reflect on this.

Regarding the clarification deemed necessary for the multiple instances of packets in train-to-track messages (see EECT 08/09/15): both the UNISIG and EUG inputs are reviewed. The UNISIG proposal to specify both the trackside and on-board requirements separately is retained. The EUG counter proposal to express them in a positive way is also retained, however substituting “only one” with ‘at most one” and not retaining the term “for the same direction” for the train-to-track messages, which do not have any direction.

Regarding the UNISIG input for the Excel file itself (new column 02/10/15), ERA confirms that in chapter 2 a bundle of UNISIG comment had never been processed and that replies are provided in the attachment "Classification_SRS_clauses_v5_EECT081015.xlsx".

Regarding the UNISIG comment on the way chapter 6 clauses should be interpreted, ERA recognises that the proposed inheritance principle cannot fly for clauses of type “clause x.x.x.x shall be replaced with “yyyyyyy”” and that most likely a case by case double classification (replacement clause + replacing clause) is needed.

With the exception of the forgotten ones in chapters 2 and of the general one in chapter 6, all the other items marked as “D” are reviewed and agreed; see cells highlighted in blue in the attachment "Classification_SRS_clauses_v5_EECT081015.xlsx".

ERA 21/10/15See attachment "Classification_SRS_clauses_v6.xlsx" for a revised classification of the chapter 6 so called "replacement clauses". This also gave rise to a few other adjustments, see ch3 line 1013, ch6 lines 37&37 and ch8 lines 55 to 62.See attachment "SUBSET-026-9 v342_211015.docx" for an updated

chapter 9, as per conclusions from the EECT meetings held on September and October 2015.

UNISIG 28/10/15See attachment "Classification_SRS_clauses_v6-U.xlsx" for UNISIG comments on file "Classification_SRS_clauses_v6.xlsx" posted by ERA on 21/10/15. These comments appear in column "U 27/10/15" of sheets "Chapter2" and "Chapter6" of the attachment. Sheet "Chapter3" of the attachment also contains a column "U 27/10/15" used only to express UNISIG agreement on modification proposed by ERA for line 1013.See attachment "SUBSET-026-9 v342_211015-U.docx" for UNISIG comments on file "SUBSET-026-9 v342_211015.docx" posted by ERA on 21/10/15.

EUG 29-10-2015We do not agree with the added clause 9.3.2.3.First of all UNISIG has not given any examples to justify the need of this clause.Secondly, this clause undermines the classification between requirements and informative clauses. If the word "shall" is considered sufficient in these combined clauses to distinguish between the requirement part and the informative part, that criteria could in fact be applied in the same way to all clauses, so what is then the argument for the introduction of this requirement/informative classification?We should define at least a consistent concept.Either we only distinguish between onboard and trackside clauses and leave it to the reader to detect the requirements on the basis of the word "shall", or, alternatively, we could of course split any combined requirement/informative clauses in their respective parts (if there would be such clauses).

EECT 03/11/15The comments from UNISIG (28/10/15) on chapter 2 and 6 classification are discussed and agreed. See cells highlighted in blue in the attachment "Classification_SRS_clauses_v7_EECT031115.xlsx".Post meeting note: the cells “SRS modification” in ch3 lines 523 and 1709 are also slightly amended (implementation issue in SRS 3.4.2).After this last review round, the agreed classification for the SRS 3.4.0 is successfully achieved.The next step will consist in re-iterating the classification exercise for either the modified clauses or the added new clauses brought in the SRS 3.4.2.

The EUG comment (29/10/15) on SUBSET-026 chapter 9 clause 9.3.2.3 is then discussed. ERA recalls that the “primary” purpose of the classification exercise is to isolate the on-board requirements, which consequently also consists in identifying indirectly the trackside requirements (also identified with the keyword “shall”) and the clauses which do not belong to any of these two categories. ERA also observes that there might be some tables classified as requirement, which do not actually include the keyword “shall”. It is therefore wondered whether the chapter 1 clause 1.7.1.1 should not have been amended to reflect the outcome of the classification

exercise.

ERA 26/11/15The clause 1.7.1.1 was actually an early "classification" tentative, made by discriminating (through the keyword "shall") in the SRS which are the requirements to be complied with, without any distinction between on-board and trackside. Actually this clause 1.7.1.1 is fully superseded by the classification exercise and in addition it was wrong for the following reasons: - there are numerous tables (e.g. mode transition tables 4.6.2&3) which do not contain the keyword shall but do consist of requirements - almost all the trackside requirements already contain the keyword "shall" but are however by definition optional as per clause 1.7.1.3. Only very few of them contain the keyword "may" and are so far classified as requirement.Regarding the discussion raised by EUG on clause 9.3.2.3: we still think that the keyword "shall" is useful to identify accurately which sentence inside a clause must be complied with, especially when a clause contain several sentences, not all using the keyword "shall". Any systematic split of clauses as suggested by EUG (29/10/15) would make the SRS much less readable.

It is therefore proposed to reshuffle the sections 1.7 and 9.3 accordingly, see details in the attachments "SUBSET-026-1_CR1266_261115.docx" (parts highlighted in blue) and "SUBSET-026-9_CR1266_261115.doc" (revision marks vs v3.4.2).

Regarding the classification exercise itself, see attachment "Classification_SRS_clauses_v8.xlsx" where all the modified cells or new lines are highlighted in blue. In particular: - all clauses impacted by B3R2 CRs are marked with the CR number - other occurrences of wrongly numbered bullets have been detected - some clauses are marked with a "A" or "D", due to further findings (e.g. rare use of "may" for TRK requirements) UNISIG 04/12/15See attachment "CR1266 - U 20151204.zip" for U comments on updated solution proposal posted by ERA on 26/11/15.This attachment contains:- comments on "SUBSET-026-1_CR1266_261115.docx"- comments on "SUBSET-026-9_CR1266_261115.doc"- comments on "Classification_SRS_clauses_v8.xlsx" (the U comments appear in column O "U comments" of sheets 1 to 7 of file "Classification_SRS_clauses_v8-U.xlsx" contained in this attachment. U has no comments on the modifications brought to the classification of Chapter 8 clauses).

EECT 08/12/15The UNISIG comments dated 04/12/15 on SRS chapters 1 & 9 are discussed and agreed, see details in the attachments "SUBSET-026-1_CR1266_EECT081215" and "SUBSET-026-9_CR1266_EECT081215.doc".Regarding the comments embedded in the file

"Classification_SRS_clauses_v8-U.xlsx, they are all agreed.See cells highlighted in blue in the attachment "Classification_SRS_clauses_v8_EECT081215.xlsx" for details.

ERA 16/12/15See cells highlighted in blue in the attachment "Classification_SRS_clauses_v9.xlsx" for the last round of amendments, further to the overall CR consolation phase finalised in the EECT 08/12/15 and to the inclusion of CR1283 in B3R2.

ERA 26/04/16Further to the reopening of the CR1249, see cells highlighted in blue in the attachment "Classification_SRS_clauses_v10.xlsx" for the resulting modifications.

EUG 04-05-2016Agreed

UNISIG 09/05/2016Agreed.

Supporting document(s) for Justification/Discussion for Solution

Classification_SRS_clauses_v1_SG 20150227.xlsxClassification_SRS_clauses_v1_EUG_20150304.xlsxSRS classification summary EUG 20150304.docxSRS classification summary EECT_090315.docxClassification_SRS_clauses_v2.xlsxClassification_SRS_clauses_v2-U.xlsxClassification_SRS_clauses_v3_EECT080715.xlsxCR1266_otherSRSmods.zipCR1266_otherSRSmods_SG20150901.zipSUBSET-026-9 v342_SG20150901-EUG.docxClassification_SRS_clauses_v4.xlsxSUBSET-026-1_CR1266_EECT080915.docxSUBSET-026-9 v342_EECT080915.docxClassification_SRS_clauses_v4_EECT080915.xlsxClassification_SRS_clauses_v4-U.xlsxClassification_SRS_clauses_v5_EECT081015.xlsxClassification_SRS_clauses_v6.xlsxSUBSET-026-9 v342_211015.docxSUBSET-026-9 v342_211015-U.docxClassification_SRS_clauses_v6-U.xlsxClassification_SRS_clauses_v7_EECT031115.xlsxSUBSET-026-1_CR1266_261115.docxSUBSET-026-9_CR1266_261115.docClassification_SRS_clauses_v8.xlsxCR1266 - U 20151204.zipSUBSET-026-1_CR1266_EECT081215.docxSUBSET-026-9_CR1266_EECT081215.docClassification_SRS_clauses_v8_EECT081215.xlsxClassification_SRS_clauses_v9.xlsxClassification_SRS_clauses_v10.xlsx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for

Economic Evaluation Submitting Recognised Organisation

ERA (European Railway Agency)

Contact person name A. HougardyContact Person e-mail adress alain.hougardy@era.europa.euEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2014-12-19 06:19:00 PMLast modification date 2016-05-13 02:42:04 PM

Identification number 1273State Presented_to_ECHeadline Impact of UIC 544-1 new versionImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References Subset-026 V340Error/Enhancement ErrorProblem/Need description The paragraph in 3.13.2.2.5.2 of the SRS specifies that the length

correcting kappa-factor should not be taken into account when acquiring the BWP. The paragraph refers to two specific sections in the 4th edition of UIC 544-1 regarding length correction for passenger trains and freight trains in P. In the meantime a 5th edition of UIC 544-1 has been released, where kappa correction for G braked trains has been defined. This means that paragraph 3.13.2.2.5.2 should be updated accordingly.Note that a version 6 of UIC 544-1 has also been released, but without any change in the relevant sections compared to version 5.

Supporting document(s) for problem/need descriptionSolution Proposal by submitter Update SRS paragraph 3.13.2.2.5.2 to say:

Note: the conversion model has been designed assuming that all the provisions laid down in the UIC leaflet 544-1, with the exception of sections 9.1.2, 9.2.2 and 9.3.3, apply for the acquired brake percentage.

Supporting document(s) for solution proposalAgreed Solution Modify SUBSET-026 v3.4.0 as follows:

In clause 3.13.2.2.5.2, replace "UIC leaflet 544-1, with the exception of sections 9.1.2 and 9.2.2" with "UIC leaflet 544-1 6th edition, with the exception of sections 9.1.2, 9.2.2 and 9.3.3"

Modify SUBSET-040 v3.3.0 as follows:

In clause 3.1.1.1, replace "UIC Leaflet 544-1, 4th Edition" with "UIC Leaflet 544-1, 6th edition"

Supporting document(s) for agreed solutionJustification/Discussion for Solution

UNISIG 27/08/15CR proposes to modify SRS clause 3.13.2.2.5.2 to refer to the new section of UIC 544-1. We understand that the conversion model is based on the principle that the Kappa correction factor is excluded from the calculation and therefore this new UIC leaflet section has to be added in clause 3.13.2.2.5.2. Is our understanding correct? Has the solution proposal been checked with the authors of the conversion model?

On a more general aspect, what is the process followed to detect modifications in non-Annex A documents which impact Annex A documents? In the specific case of UIC leaflet 544-1, this CR identifies the need to update SRS clause 3.13.2.2.5.2. But this leaflet is also referred to for instance by S-040. Does this new version of the UIC leaflet impact S-040 clause 4.4.1.2.1.1? At least, section 3.1.1.1 of S-040 has to be amended to refer to version 6 of the leaflet instead of version 4. We cannot imagine that S-026 and S-040 would be based on two different versions of this leaflet. Should this modification of S-040 also be part of this CR?

In addition, unlike e.g. S-040, S-026 does not provide the version of UIC leaflet 544-1 it refers to. Is this OK? How can it be made sure that the appropriate version of this UIC leaflet will be considered by the S-026 users? Has the version 4 of the leaflet to be considered for a B3 MR1 train and the version 6 for a B3 R2 train? If yes, how can an SRS user know that? Should it be via the CCS TSI text?

EUG 02-09-2015Regarding the question in the first paragraph of the UNISIG entry: your understanding is correct and yes, the solution proposal has been checked with Olaf Groepler, the leader of the UIC group which defined the conversion model.

Regarding the remaining UNISIG concerns, these are not for EUG to answer, but need to be discussed with ERA in the EECT.

EECT 08/09/15ERA, stressing that the general aspects raised by UNISIG (see entry 27/08/15) cannot be addressed by the EECT, proposes to adopt the following: to refer directly to the sixth edition of the UIC leaflet 544-1 in the SRS clause 3.13.2.2.5.2 and to replace “4th edition” with “6th edition” in the SUBSET-040 3.1.1.1.The proposal from ERA is agreed.

Supporting document(s) for Justification/Discussion for SolutionPreliminary Assessment of

BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

EEIG (ERTMS users group)

Contact person name R. DijkmanContact Person e-mail adress rdijkman@ertms.beEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number EEIG439List of assigned WG(s)Severity Interoperability and non safety relatedTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2015-03-05 01:07:01 PMLast modification date 2016-01-06 04:11:04 PM

Identification number 1275State Presented_to_ECHeadline Eurobalise transmission susceptibility requirements not linked to

interoperabilityImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References SUBSET-036 v3.0.0, 6.7.4 Error/Enhancement ErrorProblem/Need description The whole SUBSET-036 section 6.7.4 contains requirements

dealing with the compatibility between the Eurobalise on-board transmission equipment and radiated noise from the rolling stock.The limits specified in this section 6.7.4 give the impression that a vehicle emitting noise beyond these limits cannot be eligible for fitment with an ETCS on-board equipment.Even though these limits would be agreed by the rolling stock manufacturers, they should at most be part of a voluntary standard (i.e. not in the TSI CCS), since they are not as such relevant for track-to-train interoperability.

Supporting document(s) for problem/need descriptionSolution Proposal by submitter In section 2 I, delete the entry G "UNISIG SUBSET-116; Eurobalise

On-board Equipment, Susceptibility Test Specification"

Replace the whole content of section 6.7.4 with the following sentence: "The manufacturer shall provide information related to the susceptibility of the on-board equipment, to support its integration in the vehicle. This information should make reference to recognised

technical standards”.Supporting document(s) for solution proposalAgreed Solution Modify SUBSET-036 v3.0.0 as follows:

In section 2 I, delete the entry G "UNISIG SUBSET-116; Eurobalise On-board Equipment, Susceptibility Test Specification"

Replace the whole content of section 6.7.4 with the following sentence: "The manufacturer shall provide information related to the susceptibility of the on-board equipment, to support its integration in the vehicle. This information should make reference to recognised technical standards”.

Supporting document(s) for agreed solutionJustification/Discussion for Solution

UNISIG 03/07/15We propose to modify Subset-036 v3.0.0 by adding new clauses at the end of section 6.7.4.1 to read: “The signals and immunity levels of Table 22 aim at representing traction and converter noise. Single events, such as MCB opening/closing and pantograph manoeuvring are not yet investigated.The signals and immunity levels of Table 23 aim at representing more continuously appearing interference.The levels in both tables apply to immunity testing only, and shall not be applied for authorisation of rolling stock.”

EUG 06-07-2015It is not our competence to check this proposal. We trust that whatever ERA and UNISIG agree is acceptable.

ERA 20/08/15The text proposed by UNISIG (03/07/15) clearly explains that the values for immunity provided should give a good confidence that the BTM is compatible with certain emission of a vehicle. Anyway, it is also clear that the confidence is limited by the fact that the analysis of possible emissions is not complete and, even more important, because there is neither obligation nor commitment for vehicle supplier to respect the limits.

While it is reasonable to inform suppliers of ETCS about the current state of knowledge, there is however no ground to make the respect of these immunity limits legally binding. Such mandatory requirement would create costs in the certification process that are not compensated by any advantage for the ETCS supplier, that will have in any case to check for each type of vehicle whether the respect of these limits is sufficient to ensure compatibility. Being the respect of the limits not part of requirements for the vehicle, possible incompatibilities will have to be solved with modifications negotiated case by case, i.e. exactly in the way that is followed today.The case could also occur, where a supplier of ETCS already knows the emissions of the vehicle, but has to comply also with legally binding limits that are known to be not applicable for the intended use of the product.

As a consequence, the information currently provided in the

mandatory Eurobalise specification is suitable for an informative document, but cannot be part of legally binding requirements. These limits are in fact an interface between ETCS and train and, like all interfaces, must be respected by both sides.The text that UNISIG proposed (03/07/15) shows that additional work, with the participation of all relevant stakeholders, is necessary to specify limits value that can give presumption of compatibility between ETCS and vehicles respecting them.

Conclusion: the solution proposal by submitter should be retained for the above reasons.

Supporting document(s) for Justification/Discussion for SolutionPreliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

ERA (European Railway Agency)

Contact person name A. HougardyContact Person e-mail adress alain.hougardy@era.europa.euEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2014-11-25 01:25:23 PMLast modification date 2016-01-06 04:11:04 PM

Identification number 1277State Presented_to_ECHeadline D7 of SoM procedure is reached while no Mobile Terminal is

registered yetImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision 2012/696/EU)Documents and/or References Subset-026 v3.4.0, section 5.4.Error/Enhancement ErrorProblem/Need description The decision box D7 in the SoM procedure can be reached while no

Mobile Terminal is registered yet.This will lead to a performance loss because the S10 state of the SoM procedure will be entered and the driver will then have to re-

enter the level (S2) and perform the operations of step S3 before the ETCS on-board contacts the RBC.Having no registered Mobile Terminal when reaching D7 can happen frequently, in fully nominal situations: A Mobile Terminal can use the manual mode. This is even the default mode (see 4.4.10.3.5 in the “Radio Transmission FFFIS for EuroRadio” (A11T6001 v12.4)).It will therefore wait for the registration order coming from the ETCS on-board to start its registration to the network.According to Subset-093, a registration to the radio network can take up to 40 s as per requirement 6.3.7.3 of Subset-093. It could even be longer as Subset-093 is informative only.Let’s consider the following scenario:The ETCS on-board of a train becomes powered-on. The opening of the desk takes place at the power-on or immediately after this one.The ETCS on-board performs its initialization phase. As soon as this one is terminated, the ETCS on-board generates the order to register to the Mobile Terminal (MT).At the reception of this order, the MT starts its registration.Once the ETCS on-board terminates its initialization phase, a desk is already open (or the opening of the desk takes place immediately after this initialization phase is terminated).The driver is requested to enter his/her id.The entry of this id can take a few seconds only.The driver does not enter the train running number in S1 and he/she does not set nor remove VBCs.This train is fitted with a Cold Movement Detector. The stored position and level (level 2) have been confirmed at power-on as being valid. The decision box D7 is reached while there is no MT registered yet.

EECT 15/04/15The check of the plausibility of the scenario described by the submitter has given rise to the following:

From railway point of view the only problem is the following:In the cases where the radio network will not be registered when SoM reaches step D7, then according to A29 in the SoM, ‘The ERTMS/ETCS on-board equipment shall inform the driver that the Radio Network registration has failed’. However, the registration has not failed since it is still within the 40s from SS93. This is seen as an inconsistency since the driver is informed of an error which did not occur.

A survey conducted within UNISIG revealed that the behaviour of the mobile terminal in manual mode depends on the mobile terminal supplier.Some mobile terminals register to the last network id received if available at their power-up (and after their initialisation phase) while others wait for the registration command coming from the ETCS on-board command to register.In case the mobile terminal registers at its power-up, the time between the moment the mobile terminal is powered-up and the moment it is registered to the radio network depends on product characteristics which are mobile terminal supplier specific (duration of the mobile terminal initialisation phase) and network “quality”.

Considering also that the duration of the ETCS on-board initialisation phase is ETCS supplier specific, it is difficult to quantify the plausibility of the described scenario.Regarding EUG opinion about informing the driver that the Radio Network registration has failed while the registration is still on-going, we understand this opinion.However, in case the mobile terminal registers at its power-up, i.e. without any registration command coming from ETCS, there is no means for the ETCS on-board to know that the 40 s (see Subset-093) are elapsed. In other words, the ETCS on-board does not know the start event to count the 40 s. Based on the above, UNISIG would not be opposed to the rejection of the CR.

Conclusion: from U survey it rather looks like that the MT functionality is underspecified (EIRENE) . On top of that the 40s come from an informative document (SUBSET-093)

Supporting document(s) for problem/need descriptionSolution Proposal by submitterSupporting document(s) for solution proposalAgreed Solution Modify SUBSET-026 v3.4.0 and ERA_ERTMS_015560 v3.4.0 as

described in the attachment "ERA_solution_for_CR1277_141215.docx"

Supporting document(s) for agreed solution

ERA_solution_for_CR1277_141215.docx

Justification/Discussion for Solution

ERA 25/08/15See solution proposal in attachment "ERA_solution_proposal_for_CR1277_250815.docx"

UNISIG 27/08/15See attachment "ERA_solution_proposal_for_CR1277_250815-SG.docx" for U comments on solution proposal posted by ERA on 25/08/15.

EUG 02-09-2015We support the UNISIG comments on the ERA proposal with the following two remarks.1) Comment on 5.4.3.2 box S4 (Php3). We agree that some clarification is needed. We do not see however any need to have more than one timer (as suggested by the plural in the comment), because there can be only one condition to exit S4 via E7. One timer is sufficient and it should start as soon as the first MT is ordered to register. Since the MTs are always ordered due to a single trigger event (e.g. power-up) we assume that the time between the orders to the individual MTs is negligible.2) If the MT reports back to the ETCS on-board that the registration has failed we do not need to wait the full 40s time-out. Therefore this event should be added to S4 as an exit condition to go to A29.

EECT 07/10/15The comments posted by UNISIG (27/08/15) and EUG (02/09/15) are discussed. It is agreed to close the CR with all the proposals resulting from agreed replies, see tags “EECT071015” in the Word comments inside the attachment

"ERA_solution_proposal_for_CR1277_EECT071015.docx".See attachment "ERA_solution_for_CR1277_071015.docx" for the updated solution.

EECT 08/12/15In the DMI part, the reference to "Figure 109 – Main window" must be added in the column "window" of line S4.See attachment "ERA_solution_for_CR1277_141215.docx" in the field "Agreed Solution".

Supporting document(s) for Justification/Discussion for Solution

ERA_solution_proposal_for_CR1277_250815.docxERA_solution_proposal_for_CR1277_250815-SG.docxERA_solution_proposal_for_CR1277_EECT071015.docxERA_solution_for_CR1277_071015.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name P. PrieelsContact Person e-mail adress philippe.prieels@transport.alstom.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number 1179List of assigned WG(s)Severity Performances impact, non interoperability and non safety relatedTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2015-02-28 11:32:28 PMLast modification date 2016-01-06 04:15:10 PM

Identification number 1278State Presented_to_ECHeadline SUBSET-074 upgrade to Baseline 3 Release 2 (B3R2)Impacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision (EU) 2015/14)Documents and/or References SUBSET-074-2-1 to 12 v.3.0.0 Error/Enhancement ErrorProblem/Need description This is the cover CR for the amendment of SUBSET-074-2 in

relation to B3R2Supporting document(s) for problem/need descriptionSolution Proposal by submitterSupporting document(s) for

solution proposalAgreed Solution Replace the content of SUBSET-074-2-1 to 12 v3.0.0 with the

content of the attachments "SUBSET-074 v302 part 1oo3.zip", "SUBSET-074 v302 part 2oo3.zip" and "SUBSET-074 v302 part 3oo3.zip".

Supporting document(s) for agreed solution

SUBSET-074 v302 part 1oo3.zipSUBSET-074 v302 part 2oo3.zipSUBSET-074 v302 part 3oo3.zip

Justification/Discussion for Solution

UNISIG 24/08/15See attached files "SUBSET-074 v301 part 1oo3.zip", "SUBSET-074 v301 part 2oo3.zip" and "SUBSET-074 v301 part 3oo3.zip" for a solution proposal.This solution proposal includes the modifications resulting from CRs 1094 and 1242 plus additional points resulting from STM WP review of the v3.0.0 of the document (see attached file "Unisig_s074_COM_STM_WP.doc" for these additional points).

Note: icons and sounds have not changed compared to Subset-074 v3.0.0.

EUG 02-09-2015We do not have the competence to review these test specifications.

ERA 02/10/15See review comments in attachment "SUBSET-074v301ERAreview.docx"

EECT 07/10/15The ERA review comments 02/10/15 are discussed, see tags “EECT071015” in the attachment "SUBSET-074v301ERAreview_EECT071015.docx".

UNISIG 20/10/15See attached files "SUBSET-074 v302 part 1oo3.zip", "SUBSET-074 v302 part 2oo3.zip" and "SUBSET-074 v302 part 3oo3.zip" in the field "agreed solution" for updated solution proposal as per conclusions of EECT 07/10/15. See attached file "SUBSET-074v301ERAreview-U.docx" for the supporting review sheet.

Supporting document(s) for Justification/Discussion for Solution

SUBSET-074 v301 part 1oo3.zipSUBSET-074 v301 part 2oo3.zipSUBSET-074 v301 part 3oo3.zipUnisig_s074_COM_STM_WP.docSUBSET-074v301ERAreview.docxSUBSET-074v301ERAreview_EECT071015.docxSUBSET-074v301ERAreview-U.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

ERA (European Railway Agency)

Contact person name A. HougardyContact Person e-mail adress alain.hougardy@era.europa.euEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number List of assigned WG(s)Severity OthersTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2015-03-31 12:31:05 PMLast modification date 2016-01-06 04:11:05 PM

Identification number 1280State Presented_to_ECHeadline System version number increment for B3R2Impacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision (EU) 2015/14)Documents and/or References SUBSET-026 v3.4.0 ch6 and 7.5.1.79, SUBSET-039 v3.1.0 ch6Error/Enhancement EnhancementProblem/Need description As the ETCS B3R2 consists actually of a new baseline, the ETCS

system version number increment must be materialized in the relevant parts of the ETCS specifications.

Supporting document(s) for problem/need descriptionSolution Proposal by submitter See attachment

"ERA_solution_proposal_for_CR1280_300615.docx"Supporting document(s) for solution proposal

ERA_solution_proposal_for_CR1280_300615.docx

Agreed Solution Modify SUBSET-026 v3.4.0 and SUBSET-039 v3.1.0 as described in the attachment "ERA_solution_for_CR1280_161215.docx"

Supporting document(s) for agreed solution

ERA_solution_for_CR1280_161215.docx

Justification/Discussion for Solution

UNISIG 01/09/15See file in attached zip archive "CR1280 U2015-09-01" for the UNISIG comments to the solution proposal by submitter.

EUG 02-09-2015The solution proposal by submitter is agreed. We do not consider the UNISIG comments really relevant.

EECT 07/10/15The UNISIG comments (01/09/15) are discussed. It is agreed to close the CR with all the proposals resulting from agreed replies, see tags “EECT071015” in the Word comments inside the attachment "ERA_solution_proposal_for_CR1280_EECT071015.docx" and resulting solution in the attachment

"ERA_solution_for_CR1280_071015.docx".

EECT 08/12/15The following amendments to the Subset-039 related part of the solution 07/10/15 are agreed:- In clause 6.2.4.1.8 of Subset-039: the references in the agreed solution are referring to clauses in section 6.3.4, but must refer to clauses in section 6.2.4 instead- In clause 6.2.4.3, requirements for T2 translation, regarding the numbering of clauses: it seems that in the agreed solution, it had been forgotten to manually assign a lower heading level to the clauses of this section (while it was correctly done for corresponding sections, defining the requirements for T1, T3 and T4, in the agreed solution). This corrupts the entire numbering of section 6.2.4 from 6.2.4.3 onwards.- Reference to clause 6.5.1.2 in clause 6.2.4.9.2 of the agreed solution should be updated to a reference to clause 6.2.4.1.1. - Reference to clause 6.4.1.8 in clause 6.2.5.2 of the agreed solution should be updated to a reference to clause 6.2.3.8.

See attachment "ERA_solution_for_CR1280_161215.docx" in the field "Agreed Solution"

Supporting document(s) for Justification/Discussion for Solution

CR1280 U2015-09-01.zipERA_solution_proposal_for_CR1280_EECT071015.docxERA_solution_for_CR1280_071015.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

ERA (European Railway Agency)

Contact person name A. HougardyContact Person e-mail adress alain.hougardy@era.europa.euEndorsed by Recognised Organisation(s)Project Information Submitter Reference Number List of assigned WG(s)Severity Interoperability and non safety relatedTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2015-06-29 04:11:00 PMLast modification date 2016-01-06 04:11:05 PM

Identification number 1283State Presented_to_EC

Headline Inconsistent use of the terms EOA and LOAImpacted System ETCSReference Baseline Release Baseline 3 (TSI CCS annex A modified by decision (EU) 2015/14)Documents and/or References SUBSET-023 v3.1.0, SUBSET-026 v3.4.0, SUBSET-040 v3.3.0,

SUBSET-041 v3.1.0, SUBSET-091 v3.3.0, ERA_ERTMS_015560 v3.4.0

Error/Enhancement ErrorProblem/Need description The following scenario was observed:

1. OBU operates in L2/FS.2. In scope of performing a transition from L2 to L0 the RBC grants an MA with LoA (target speed at EoA greater than zero) and the track description (SSP, etc.) extending further beyond.The target speed is not time limited.3. OBU receives that MA.4. RBC sends a Conditional Emergency Stop with the requested stop location at exactly the same location as the LoA to OBU.5. OBU receives that Conditional Emergency Stop.6: OBU sends an Acknowledgement of Emergency Stop indicating “Conditional Emergency Stop considered” (Q_EMERGENCYSTOP=0) to RBC. However the OBU does not consider a new EoA and SvL at the requested stop location.7: OBU continues operation according to the MA received before.

Consequently the train moves faster than expected by the railway undertaking and the RBC supplier.In the specific situation the train was observed moving at 90km/h at a location where it was expected to move not faster than 40km/h.

The OBU supplier claims that there are issues to be clarified in the ETCS specifications. These issues mostly relate to conflicting definitions of EoA and LoA in both Subset-026 and Subset-023, as well as to the inconsistent use of the term EoA throughout Subset-026. In some cases EoA is supposed to apply also to LoA, but in other cases it is being used to apply to the EoA only (with LoA being intentionally excluded as an entirely separate entity).

Supporting document(s) for problem/need descriptionSolution Proposal by submitter An exhaustive analysis of the use of the terms EOA and LOA

throughout the annex A documents has been provided by the involved OBU supplier (on request by ERA) and is thoroughly assessed by ERA, together with a comprehensive solution proposal, see attachments "EOA_LOA_revERA_041215.XLSX" and "SUBSET-026-3 v342_EOA-LOA_041215.doc" for details.

Supporting document(s) for solution proposal

EOA_LOA_revERA_041215.XLSXSUBSET-026-3 v342_EOA-LOA_041215.doc

Agreed Solution Modify SUBSET-023 v3.1.0, SUBSET-026 v3.4.0, SUBSET-040 v3.3.0, SUBSET-041 v3.1.0 and SUBSET-091 v3.3.0 as described in the attachments "ERA_solution_for_CR1283-part1_161215.xlsx" and "ERA_solution_for_CR1283-part2.zip"

Supporting document(s) for agreed solution

ERA_solution_for_CR1283-part1_161215.xlsxERA_solution_for_CR1283-part2.zip

Justification/Discussion for UNISIG 15/12/2015

Solution See attached file "EOA_LOA_revERA_041215-U.XLSX" for U comments on solution proposal by submitter. U comments appear in column F "SG comments" of sheets "Subset-023v3.1.0" and "Subset-026v3.4.0" of this attached file.

EECT 15/12/15See attachments "EOA_LOA_revERA_151215.xlsx" and "SUBSET-026-3 v342_EOA-LOA_151215.docx" for the amended solution resulting from the UNISIG comments 15/12/15

ERA 16/12/15The replacement of "V_LOA" with "LOA speed" in figures 43, 44 and in clause 3.13.9.2.7 is duly mentioned in the attachment "SUBSET-026-3 v342_EOA-LOA_151215.docx" but is not mentioned in the attachment "EOA_LOA_revERA_151215.xlsx".The headline "TRAIN TRIP" is also missing in the line 9 of the SUBSET-023 sheet.See attachment "ERA_solution_for_CR1283-part1_161215.xlsx" in the field "Agreed Solution".

Supporting document(s) for Justification/Discussion for Solution

EOA_LOA_revERA_041215-U.XLSXEOA_LOA_revERA_151215.xlsxSUBSET-026-3 v342_EOA-LOA_151215.docx

Preliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

ERA (European Railway Agency)

Contact person name A. HougardyContact Person e-mail adress alain.hougardy@era.europa.euEndorsed by Recognised Organisation(s)Project Information Safety related issue detected in the Swiss Gotthard project during

commercial operationSubmitter Reference Number List of assigned WG(s)Severity Safety relatedTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2015-12-04 02:40:59 PMLast modification date 2016-01-06 04:11:05 PM

Identification number 1284State Presented_to_ECHeadline SUBSET-092 upgrade to Baseline 3 Release 2 (B3R2)Impacted System ETCS

Reference Baseline Release Baseline 3 (TSI CCS annex A modified by decision (EU) 2015/14)Documents and/or References SUBSET-092-1 v3.0.0 and SUBSET-092-2 v3.0.0Error/Enhancement EnhancementProblem/Need description This is the cover CR for the amendment of SUBSET-092-1 and

SUBSET-092-2 in relation to B3R2Supporting document(s) for problem/need descriptionSolution Proposal by submitterSupporting document(s) for solution proposalAgreed Solution Modify indexes 39 and 40 as per content of attachment "S-092

v301.zip"Supporting document(s) for agreed solution

S-092 v301.zip

Justification/Discussion for SolutionSupporting document(s) for Justification/Discussion for SolutionPreliminary Assessment of BenefitsSupporting document(s) for preliminary Assessment BenefitsEconomic EvaluationSupporting document(s) for Economic Evaluation Submitting Recognised Organisation

UNIFE (Union of European Railway Industries)

Contact person name P. PrieelsContact Person e-mail adress philippe.prieels@transport.alstom.comEndorsed by Recognised Organisation(s)Project InformationSubmitter Reference Number List of assigned WG(s) UNISIG Super Group

Severity Performances impact, non interoperability and non safety relatedTarget Baseline Release ETCS B3R2Reason for Error/Enhancement reclassificationReason for rejectionReason for postponementSuperseding CRList of superseded CRs Date of Submission 2015-11-25 09:42:28 PMLast modification date 2016-01-06 04:11:05 PM