EECT #08 for the B3 next release
Minutes of Meeting
EECT #10 for the B3 next release
Lille, 09th and 10th June 2015
1. Adoption of the agenda and approval of the minutes for the meeting on 12, 13/05/2015
The agenda is adopted however the point 2 will be addressed only after completion of point 3.
The minutes of the EECT meetings held on 12&13/05/15 are agreed with modifications, see revision marks in the file “Minutes_EECT_090615_v2revmarks.docx” distributed separately.
Regarding the following EUG comment in the L. Arena’s email:
· Comment 1 /Input 1249 (BDK): – the comment is rejected, because no such input was processed during the meeting. However, the input will be posted in the database and addressed later.
2. B3 next release – Triage
The following inputs (see embedded files below) was received prior to the meeting, as per various actions allocated to UNISIG:
a) Review of the list of open actions and pending assessments of CRs
Item not covered, due to lack of time.
b) Assessment of new CR received
Item not covered, due to lack of time.
c) Project Plan
The Agency reminds that the next EECT meeting has been shifted to 8th and 9th July. The agency also requests to the attendance to block 10th September and 8th October in their agendas in case it would be needed to hold 3 days meetings before the final delivery.
2 / 16
/ Minutes of MeetingEECT #08 for the B3 next release
3. Change Requests - Technical Resolution
CR / Headline / DISCUSSION/Decision /0741 / Packet data transmission for ETCS / In relation to action 09.01, the U 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 embedded file below:
In particular an important clarification takes place for the U 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. U 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 U, 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 U comment #4.
Both EUG and U are requested to state their most preferred solution and their less preferred solution (with a rationale), amongst the 5 solutions exhaustively analysed in the above embedded file:
· 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.
· U 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 (see above embedded file) and the positions of EUG and U, 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 incriminated DK packet numbers. ERA considers this statement inacceptable. It is a fact that the 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 relation to the detailed review of the EUG document, the following actions are identified:
· Regarding the U question whether roaming will always be available in GPRS networks, or whether e.g. the on-board has to be in the same network area as the home KMC:
Action 10.01 ERA(01/07/2015) to check with UIC whether harmonised IP addressing and network interconnection is envisaged
· Regarding the use of a unique and harmonised IP address for the CS RBCs questioned by U:
Action 10.02 all (01/07/2015): 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
· Action 10.02b U (TBD): Investigate how a DNS failure is managed as part of the CS/PS dual stack.
Post meeting note: Action 10.02b to be clarified in the next EECT meeting
· Regarding the U question on the possible need to distinguish at Euroradio level between the establishment and the maintenance of a session to know with which transmission mode the connection request has to be made:
Action 10.03 U (01/07/2015): 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?
In addition ERA highlights that a question in relation to an action from a previous EECT meeting (Action 07.09b EUG) had 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.
Action 10.04 EUG (24/06/2015): should the “use short number” selection by the driver be inhibited in case the connection set up with a PS RBC has failed?
With the above decision (solution 5 retained for PS/CS selection by the on-board) and all the decisions taken in the previous meetings (e.g. PS service set-up is both GPRS attach and PDP context activation), the full technical solution can now be developed, mostly in the SUBSET-037. U questions what tests will be done to validate this dual stack specification. U states that before the current CS stack was finalised, various tests were conducted before the specification was given the rubber stamp. ERA assumes that several tests were already conducted during the TEN-T activities and recalls that as for any other CR, no further validation will be foreseen before the end of 2015. Pending the result of action 10.04, ERA recalls that there should be no modification needed for SUBSET-026. However before the Euroradio WG starts to work out the detailed specification of the dual CS/PS stack, U suggests that a recollection of all the agreed principles is made into a single paper.
Action 10.05 EUG (24/06/2015): 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
0852 / Definition of level 2/3 area and level transition border / The U solution proposal 27/05/15 was agreed by EUG. However, ERA has spotted 2 deficiencies and tabled a counter proposal (02/06/2015).
U proposes the following editorial modifications to this ERA counter proposal:
· 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, the solution proposal is agreed (see embedded file).
U also remarks that there is an interaction between this CR and the CR 1117 solution proposals. The bullet list of clause 3.5.3.7 a) is actually moved to 3.5.3.9.1 by CR1117. This will have to be taken into account during the usual final adjustment of CR’s when drafting the documents for the B3R2.
In addition, the modification brought by this solution in 3.5.5.1 b) will likely supersede the CR 1256.
Action 10.06 U (01/07/15): to check whether CR 1256 can be superseded by CR 852 solution
1021 / Brake command revocation/acknowledgement issues / The EUG input (see LA mail dated 03/06/15) is discussed. ERA wonders whether the EUG statement “As far as we know no input will be provided by CER OPE in the short term (until an alternative to the ERA OH WG is organised)” has to be interpreted as no CER input will ever be provided till the ERA OH WG is revived. EUG clarifies that it is not the case and that a CER position is still expected. However, for the time being, EUG confirms that no consolidated position from the railways can be provided. As a consequence, the action EUG 09.02 previously allocated remains open for the next meeting.
ERA also reports that for the item 2 of the CR, the consultation of their independent expert can be summarised as follows: For that case no acknowledgement is requested, to abort the brake command could be acceptable (e.g. a T_NVCONTACT service brake reaction followed by a level transition). This behaviour could be easily explained to drivers. However, for the case an acknowledgement is requested, to abort it would be more problematic. The preferred direction would be to keep the acknowledgement and to delay any further actions (e.g. any change of mode).
1084 / Target speed masking / No input has been received prior to the meeting on the ERA solution proposal 02/06/15. The following comments are however discussed.
The solution proposal is slightly amended with the following editorial comments in 3.13.10.4.2 (see embedded file):
· U comment step 0: ellipsis (i.e. “...”) shall be used for the formulas to explicitly mention that the calculation is made from targets 1 to N
· U comment step 1: missing "or" in the formulas to explicit state that the calculation goes from targets 1 to N
· EUG comment step 1: split the second sentence in two sentences by removing the "and" following MRDT0.
In addition, U 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, U 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 U, 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.
Action 10.07 ERA (01/07/15): To investigate the two U concerns on the ERA solution proposal
1091 / Insufficient driver information in OS / The ERA solution proposal 26/05/15 was agreed by U (03/02/15) and EUG (02/06/15) prior to the meeting.
1152 / Avoid increase of permitted speed and target distance / EUG tables a new proposal during the meeting (see embedded file) which includes the feedback from TRV on the U comments posted on 04/06/15.
On the basis of this proposal, the ERA/U comments are discussed:
· The ERA comment about the condition “a new target is selected for display” is accepted.
· Regarding the U comments, it appears that most of them consider the functional requirement defined during the April EECT 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 April EECT 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. U 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”.