Minutes of the EECT Meeting # 05 for the B3 next release
Lille, 13th and 14th January 2015
1. Adoption of the agenda and approval of the minutes for the meeting on 01,02&03/12/2014
The agenda is adopted with one additional item (see AOB) and further to remarks/suggestions
from EUG (Email L. Arenas 06/01/15) and UNISIG (Email P. Prieels 12/01/15) the minutes of the
EECT meeting held on 01,02&03/12 are approved with the following modifications, see revision
marks in the embedded file
Minutes_EECT_03121
4_v2revmarks.docx
Regarding the comments in the P.Prieels’ email, which are tagged as individual comments from
J. Mattisson: ERA underlines that comments should be consolidated ones from each
representative organisation. However, all the comments from J. Mattisson are taken into
account to improve the minutes, with one exception: no one can remember that there was an
action allocated to Ingo Wendler to confirm the feasibility of the systematic GPRS attach: on the
contrary, the attendees rather remember that this was confirmed more than one time during
the meeting.
2. B3 next release – Triage
The following inputs (see embedded files and excerpts from P. Prieels emails below) were
received prior to the meeting, as per various actions allocated to EUG and UNISIG:
CR change of radio Homework for EECT5
network during SoM procedure_SG20150112.docx
20150105.docx
Email P. Prieels 05/01/15: U scoring and compatibility assessment of the following CRs:
CR “Termination of a communication session due to “error condition””
U proposes to modify the problem description as follows:
“SRS 3.5.5.1 b) requires that the ETCS on-board equipment initiates the termination of a
communication session if an error condition requiring the termination of the communication
session is detected on-board. It should be made clearer that this clause is a “glue” clause which
refers to all the requirements in the ETCS specifications explicitly requesting the termination of
the communication session.”
CR “ERTMS/ETCS on-board equipment delays regarding the speed and distance monitoring”
U agrees with the rejection of this CR.
CR “Traction cut-off issues”
U agrees with the rejection of this CR.
CR “Accuracy of distances measured on-board not considered when determining Release
Speed from MRSP”
U changes its compatibility assessment of this CR to YES.
CR ” Exhaustiveness of the list of actions not to be reverted or executed twice”
Criticality : 3
Workload : 3 (could be higher if complex reverting of actions has to be specified)
Impact on TSI specs: 2 (could be higher if complex reverting of actions has to be specified)
Compatibility: no (if the CR solution specifies a reverting, the on-board implementing the CR
solution will revert the action while the trackside does not expect so, i.e. the on-board will
restart the timer and may withdraw the MA section. A performance issue could result from this.
If the CR solution specifies the non-reverting, the SG does not see a compatibility issue since the
trackside cannot expect today any predictable reverting from the on-board. The trackside
should therefore be robust to any on-board behaviour including the non-reverting).
Email P. Prieels 12/01/15: U scoring and compatibility assessment of the following CRs:
CR “Miscellaneous editorial findings in B3 MR1“
Criticality: 2
Workload: 2 (assumption since this is “bundle” CR which whole content is not known today)
Impact on TSI specs: 1
Compatibility: yes
CR “Classification of SRS clauses“
Criticality: 3
Workload: 4
Impact on TSI specs: 3
Compatibility: yes (on the assumption that no controversial items impacting the compatibility
will be found)
a) Review of the list of open actions and pending assessments of CRs
b) Assessment of new CR received
See corresponding embedded file in minutes of the February meeting for items a) and b)
c) Project Plan: ERA informs that a new version of the project plan has been distributed. After
review of the agenda for the February meeting it is agreed to shift the "Classification of SRS
requirements" from February to March, instead CR 1078 and CR 1187 will be in the February agenda.
It is also agreed that the actions open for the CR 741 due on 15/01/2014 are shifted to 30/01/2014.
ERA also reminds that there are pending actions from CR1238 that are absolutely needed for the
next meeting.
2
It is also agreed to shift the April meeting from 7th and 8th to 15th and 16th.
3
3. Change Requests - Technical Resolution
CR
HEADLINE
0740
Unclear requirements
concerning functions active in
L2/L3 only
DISCUSSION/DECISION
The item 1 update (see U 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 and will be possibly resumed at the earliest together with the CR1021 resolution.
The U action (06/01/15) to improve the solution proposal according to the conclusion of December meeting is still
on-going. In the meantime U has prepared an intermediate document (see embedded file below), introducing the
idea of approaching, departing and current RBC. This underlying idea is to clarify in each SRS requirement where
the RBC ID/phone number is used, to which one the requirement refers to.
0933
Storing of RBC contact
information
CR933 - V3.docx
Action ERA/EUG (27/01/15): to provide a go/no go opinion for the approach presented, before U can carry on with
it
It is agreed that the next EECT discussion of CR933 will take place in the March EECT meeting.
CR
HEADLINE
DISCUSSION/DECISION
U 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 theTrafikverket 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 embedded file below:
CR1084_EUGcomm_1
50106_withERAreplies.docx
1084
Target speed masking
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).
ERA wonders why the videos prepared by ERMS solutions did not convince the EUG to discard their approach to
toggle the display of the two targets and EUG replies that they were not and they should still check this with other
different track/train data configurations.
Action EUG (04/02/15): 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.
5
CR
HEADLINE
DISCUSSION/DECISION
The CR was reopened by ERA (18/12/14), further to an interaction with CR1242 item #14.
The following U questions are addressed:

1094
Unclear stop conditions for
display of some DMI objects


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 lines
The EUG confirmed the direction taken by U approach and agreed with the ERA improvements 09/12/14.
Regarding the EUG question about the removal of the exception [5] from table 4.8.4: U clarifies that there is no
reason to keep it considering that new mode transitions from PT to SH,SN, UN have been defined.
1128
Passing Level 0 / Level NTC
border in PT mode
Regarding the modification to figure 8 (to drag back the grey area to not include the three diamond boxes D080,
085, 090), ERA/EUG underline that, in spite of the U reservations, the decision boxes and action boxes are
intemporal, which means that they need not to be inside a mode related grey area. On the contrary the note
proposed by U is uselessly misleading, at the end of the day only the set of requirements (procedure table plus the
additional one proposed) matters and is unambiguous.
ERA decision: the CR is closed with the U proposal 26/11/14 amended by the two editorial improvements tabled on
09/12/14, in spite of the U disagreement on the second one (modification to the figure 8).
Post meeting note: the text of the exception [5] below the table 4.8.4 cannot be just removed, it must rather be
replaced with “intentionally deleted”
6
CR
HEADLINE
DISCUSSION/DECISION
ERA HW 17/12/14 agreed by EUG (19/12/14) with one typo remark.
However U 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.
1129
DMI indication of level
announcement in SB
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 clause
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.
Action ERA (03/02/15): 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).
7
CR
HEADLINE
DISCUSSION/DECISION
Several problems with STM
specifications
The ERA/EUG comments (10/12/14) are reviewed during the meeting, see embedded file below:
1242

Item #2: U 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 U proposal (slightly amended) is accepted

Item #7: withdrawn by U as proposed by ERA

Item #10: the ERA comment is acknowledged by U and the enhancement proposed by U is accepted with
slight modification.
Item #12: the editorial improvement proposed by EUG is accepted
Item #14: it is confirmed that it is fully superseded by CR1094


Attachment_problems
_STM_spec_20140722_EECT140115.doc
Conclusion: the solution proposal, with the above amendments, is agreed.
U also explains that they have two new FFFIS STM related items and they wonder if they should be a new CR or to
be included in the CR 1242. The STM WG leader presents the two topics and since they appear to be substantial
and not related to each other, it is agreed to raise two distinct CRs.
Display of ETCS override in
level NTC
1245
Even though the problem depicted by the CR was recognised and validated in the triage, U 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 U proposal 17/12/14).
ERA/EUG do not support the U 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
8
CR
HEADLINE
DISCUSSION/DECISION
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 U, 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.
Action EUG (04/02/15): To draw up a table showing all the possible combinations for the override indications
depending on current level and level transitions and the use of existing buttons.
9
4. BCA
Questions regarding the methodology (Email P. Prieels 12/12/14 and Email L. Arenas 12/01/15):
Regarding the “B3 MR1 maintenance” Q4, EUG/U questions why it is not systematically
answered. EUG pointed out that CR1056 is an example contradicting this approach. ERA replies
that indeed Q4 could be answered for all CR’s but for the time being, our primary focus is the
definition of the next baseline. In that context, the Q4 is mainly relevant if Q1 or Q2 of the tab
“B3.1 definition” is answered with a No. This can indeed give an indication that the technical
solution could have to be reworked in case Q1 or Q2 is ‘No’ and Q4 is ‘Yes’. This approach will be
revised in the future if needed with possibly extending the exercise to all open CR’s in the
database.
Regarding the comment from UNISIG ‘Should the question Q2 (2.3.0d) not be “Q2: Can a 230d
Onboard not implementing that CR run a normal service on a B2 Trackside that implements that
CR”?’, U explains that this question could be useful to identify the so called “Out” CR’s. U points
out that if this exercise of detecting the “OUT” CRs is not considered by all together, it will be
done by all stakeholders separately with the risk of different conclusions from one stakeholder
to the other and possible resulting interoperability issues. ERA answers that the exercise consists
of checking the compatibility (CR by CR) of a new baseline 3.1 as it would be versus the B2 as it
is. Therefore a “B2 trackside that implements that CR” is an irrelevant consideration.
Regarding potential NTRs, EUG points out that some could arise because of grey areas in
previous baselines which are clarified in the next release. NTR could also arise to perpetuate a
national solution not implemented in the next baseline. ERA reminds that an NTR that would
contradict the harmonised specifications should go through the TSI derogation process. It is
agreed not to take into account possible NTRs in the BCA.
BCA result
See embedded file below:
BCA_CR release
2015_EECT140115.xlsx
5.
Any Other Business
Unisig asks wheter the Annexes received from the Spanish organisations during the ERA-EC-EUGIndustry visit to Ministry of Fomento will be analysed by EECT and related actions will be defined
to synchronise the work between ERA, EUG and U..
Concerning Annex 1, it is related to non conformities that Renfe has detected on the certificates
or issues that they have discovered in the projects non appearing in the certificates. These issues
do not concern the specifications (EECT scope) but rather the NSA/NoBos Working Groups or
products.
ERA clarifies that Annex2 is related to CRs where Spain has a special interest which are in any
case adressed in the framework of ERA CCM.
Page 1 of 1
Attendance list
NAME
Olivier GEMINE
Alain HOUGARDY
Oscar REBOLLO BRAVO
Robert DIJKMAN
Laura ARENAS
Alfonso LORENZO
Ron BAILES
Philippe PRIEELS
Friedemann BITSCH
Staffan PETTERSSON
Thmoas MANDRY
ORGANISATIO
ERA
N
ERA
ERA
EIM / ERTMS U.G.
EIM / ERTMS U.G.
EIM / ERTMS U.G.
CER
UNIFE/UNISIG
UNIFE/UNISIG
UNIFE/UNISIG
UNIFE/UNISIG
11
E-MAIL ADDRESS
olivier.gemine@era.europa.eu
alain.hougardy@ era.europa.eu
oscar.rebollo@ era.europa.eu
rdijkman@ertms.be
larenas@ertms.be
alfonso.lorenzo@ineco.es
ron.bailes@atoc.org
philippe.prieels@transport.alstom.com
friedemann.bitsch@thalesgroup.com
staffan.pettersson@se.transport.bombardier.com
thomas.mandry@transport.alstom.com