minutes_eect_090715_v2 - european union agency for web viewminutes of meeting. eect #08 for the b3...

Minutes of MeetingEECT #11 for the B3 next release


Lille, 08th and 09th July 2015

1. Adoption of the agenda and approval of the minutes for the meeting on 09, 10/06/2015

The agenda is adopted. However the point 2 will be addressed on day 2 depending on the progress on point 3.The minutes of the EECT meeting held on 09&10/06/15 are agreed with modifications, see revision marks in the file “Minutes_EECT_090615_v2revmarks.docx” distributed separately.Regarding the U and EUG rejected comments, see ERA replies in the Word comments still embedded in the file “Minutes_EECT_090615_v2revmarks.docx”.

2. B3 next release – TriageThe following input (see embedded file below) was already received prior to the previous meeting, as per action 08.01 allocated to UNISIG:

a) Review of the list of open actions and pending assessments of CRsb) Assessment of new CR received

See embedded excel file with the result of the discussions for items a) and b)

c) Project Plan

The agenda of the September meeting is reviewed. A review of the CRs necessitating an intermediate checkpoint in August (as requested by the Control Group) is also performed: it appears that only the HW to be performed by both UNISIG Euroradio WG and GSM-R WGs, in the frame of CRs 741, 1237, 1262 need to be covered by this intermediate checkpoint.

ERA also informs that a partial update of the specs (SUBSET-023, SUBSET-026, SUBSET-027, ERA_ERTMS_015560) has been done with a first bundle of CRs for the Test Spec WG.

1 / 16


3. Change Requests - Technical Resolution

CR HEADLINE DISCUSSION/DECISION

0741 Packet data transmission for ETCS

Review of action 10.01 (to check with UIC whether harmonised IP addressing and network interconnection is envisaged):

The file embedded here below is presented by ERA.

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.

Action 11.03 ERA (30/07/15): To check that there is a harmonized way to reach the DNS in all networks at least in EU.

The problem of an on-board reaching its home KMC from abroad is then discussed. U 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 them, 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 (Routing tables and nodes configuration), in order to allow the IP

2 / 16



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.

Action 11.04 ERA (30/07/15): 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.

With regards to this last action, 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.

Review of action 10.02 (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 EUG/ERA/U inputs are discussed.

The option to use a DNS response of type “TXT” (preferred by EUG and U) 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 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 previous meeting, ERA recalls that there is and there will be no such “for future purpose” add-ons in the

3 / 16



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".

Review of action 10.03 (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 U 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.

Review of action 10.04 (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. However the requirement to skip entering the RBC telephone number during data entry still exists by entering a special value i.e. all 1s.

See also related ERA comments 4&5 in the frame of action 10.05.

Review of action 10.05 (to wrap up all the decisions made in the previous meetings and to assemble them in a single paper enclosing the solution 5 for the selection of the transmission mode):

The ERA comments on the “ETCS over GPRS principles” document in version 2B are first discussed, see embedded file below:

4 / 16



.

Regarding the U comments, due to late delivery from U and to the huge number of raised comments, only a few of them can be addressed (see tags EECT090715 inserted inside Word comments in the file embedded below). An ad-hoc meeting is scheduled on 22/07 to deal with all these U comments.

1021 Brake command revocation/acknowledgement

issues

The CER/EUG input (01/07/15) is discussed.

The CER position is rather unclear. What justifies that this principle would be the “safest” since in the U proposal the ack is only kept for display/operational purposes but the next actions are still executed by the on-board?

The statement is also inconsistent: On one hand, CER would like to stick to the OH statement 25/05/11 while on the other hand, they are ready to accept the 3 exceptions put forward by U. ERA also underlines that the U exceptions are built on the assumptions that the actions subsequent to an acknowledgement request are still executed while they could have been put on hold as long as the driver has not acknowledged e.g. the transition to FS being delayed due to a not yet OS ack.

Considering the above, ERA stresses that only two realistic options are left within the time left for the B3R2: either remove the CR1021 from the basket or to proceed with a technical proposal that would remove any service brake command and pending ack if the corresponding function is not relevant anymore. ERA also indicates that after a second thought, this second option was also assessed by the independent operational expert as acceptable because even an ack request disappearing suddenly could help the driver to better perceive that the context has

5 / 16



changed (e.g. entry in FS mode).

However considering that there is a meeting scheduled on 13/07 between ERA and CER operational experts to review the B3R2 CRs with an operational impact, no decision is taken in case some further clarification could be brought during this meeting.

1084 Target speed masking

The U review comments against the ERA solution proposal 01/07/15 are discussed.

With the exception of comment #4 (the remark 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 U comments are accepted, see parts highlighted in yellow in the embedded file below.

Regarding the U 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.

1152 Avoid increase of permitted speed and target distance

The 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. However, the rewording initially proposed by ERA is slightly amended to “another target becomes the MRDT”, in order to ensure consistency with the CR1084 solution.

6 / 16



The U comments received prior to the meeting are addressed, see tags EECT080715 inserted inside the Word comments in the file embedded below.

There are two new open points to be resolved, see identified actions below.

Action 11.05 EUG (25/08/15): To investigate 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.

Action 11.06 EUG (25/08/15): To clarify 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,...?

1184

Missing requirement for the number of communication sessions an OBU must be capable to handle simultaneously

With 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 U agreement for the sake of their rejected comment #3.

1197 Ambiguity regarding the temporary EOAs and SvLs

Both EUG and U provided comments prior to the meeting (06/07/15) against the solution proposal by submitter.

Regarding the EUG remark: 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

7 / 16



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.

Regarding the U quote:

U is surprised by the fact that they are still the submitter of the CR: it is agreed to change the recognized organization to ERA even though the source of the issue was detected by U.

Concerning the U paper “CR1197 solution proposal - U.docx”, ERA is also surprised that U 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 U 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 U, 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 remainder of CR1197 but rather to the new CR resulting from the split. Therefore the content of the U paper “CR1197 solution proposal - U.docx” will be moved to the new CR.

The CR is closed with the solution proposal by the submitter (agreed by EUG) without U agreement.

299 Version compatibility check U had forwarded prior to the meeting the following comments on the reasons given by ERA (see ERA’s posting dated 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?

8 / 16



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 U remarks 1&2: ERA considers indeed that the CR299 and CR1229 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

9 / 16



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. U 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 U 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 onboards 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 had also forwarded 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

10 / 16



column.

Last but not least, EUG remarks that the CR299 solution proposal goes together with the one of CR1262. Since the CR1262 as a whole is currently being challenged by one EUG member (DB), it is proposed for the time being to freeze the CR 299 with the two above agreed modifications, pending the feedback from DB.

1237 KMS evolution

EUG and U 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 embedded file below) where there are misalignments between the final reply and the text in the answer column.

Review of action 10.12: no U input yet formalised. However U 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.

All the agreed review comments and the outcome of action 10.12 will be incorporated in the next version of the FFFIS, which should be very close to the final version

Action 11.07 U (22/09/15): To update the FFFIS according to the agreed review comments and to the outcome of action 10.12

Action 11.08 EUG (01/09/15): To clarify the KMS PS service setup (see comment #3 in the U review as part of action 10.05).

Action 11.08b EUG (01/09/15): To update the review sheet to fix the misaligned texts in the answer column

1254 Session establishment attempts to report mode

change

Regarding 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

11 / 16



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.

U agreed (06/07/15) prior to the meeting with ERA solution proposal 03/06/15 for item 1. Regarding item 2, U proposes to reconsider justification given by ERA on 10/06/15 in SG meeting that will take place from 14 to 16/07/15. U highlights that there was no action for this EECT meeting to reconsider this ERA’s opinion. ERA however decides not to wait and closes the CR without U agreement on item 2.

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).

1262Issues related to the initiation of a communication session by an RBC

The EUG gives an update about the information given on 02/06/15 that in Germany (Project VDE 8) it was planned to use the functionality where the RBC calls the on-board equipment: DB is currently investigating internally if this is still the case, so EUG cannot agree on the CR 1262 solution (and as a consequence also on CR 299) without feedback from DB.

ERA informs that the review by the GSM-R WGs of the part dedicated to the EIRENE FRS &SRS and to the FFFIS EURORADIO (A11T6001) is still on-going.

1265 Miscellaneous editorial findings in B3 MR1

The items marked as “D” are reviewed, see cells highlighted in blue in the embedded file below 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.

12 / 16



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 U: 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 U 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.Action 11.09 U (01/09/15): to reconsider their position with regards to the removal of the note [8] from the SUBSET-036

With the exception of the pending discussion for S36 line 2, all the decisions and solutions included in the version 4 of the Excel sheet embedded above are agreed.

1266 Classification of SRS requirements

The items marked as “D” for chapter 3&4 are reviewed, see cells highlighted in blue in the embedded file below 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 U/EUG, the item tab still needs a solution proposal.

13 / 16



Action 11.10 ERA (01/09/15): to draft a proposal for a new on-board requirement related to ch3 line 1926 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.Action 11.11 ERA (01/09/15): to clean-up the excel sheet as per agreement for ch4 line 1069

The review of the other chapters will be performed in the next meeting. Regarding the chapters 3&4, U 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.

Action 11.12 ERA (25/08/15): to draft a proposal for SRS chapter 1 modifications

Post meeting note: the file embedded above already contain an ERA review of the consolidated EUG and U comments for chapters 1, 2, 5 & 6

1275Eurobalise transmission susceptibility requirements not linked to interoperability

The U solution proposal 03/07/15 is not discussed (late input from U)

14 / 16


4. AOB

CR 1249

On request by EUG, the BDK input received the day before the May meeting is discussed (see embedded file).

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

CR 852

U recalls that the solution works in mixed areas and in L0 and LNTC only if the CR933 solution is implemented: according to ERA it means that if CR933 is not included in this release the CR 852 should not be included either.

CR1163

U informs that they have detected some flaws in the agreed solution. They will come up with a proposal to re-open the CR in order to address them.

15 / 16


Attendance list

First Name Surname Organisation Signature E-mail address

Olivier GEMINE ERA [email protected]

Alain HOUGARDY ERA [email protected]

Oscar REBOLLO BRAVO ERA [email protected]

Begona DOMINGO ERA [email protected]

Ron (only 1st day) BAILES CER [email protected]

Laura ARENAS ERTMS U.G. [email protected]

Rob DIJKMAN ERTMS U.G. [email protected]

Sharvind (only 2nd

day)APPIAH ERTMS U.G. [email protected]

Aidan (only 2nd

day)MCGRADY ERTMS U.G. [email protected]

Philippe PRIEELS UNIFE/UNISIG [email protected]

Luca REPETTI UNIFE/UNISIG [email protected]

Jan PATROVSKY UNIFE/UNISIG [email protected] (only 2nd

day)BORGHETTI UNIFE/UNISIG [email protected]

16 / 16

mailto:[email protected]

mailto:[email protected]

minutes_eect_090715_v2 - european union agency for web viewminutes of meeting. eect #08 for the b3...

Documents