Verification of Provide Position Report

[MarcBehrens]

relates to issue #237

grooming done on 28.01.2015

Related packets to Position Report coming from Subset-026-07:

• [ ] Packet 58 Position Report Parameters Configuration of Train Position Report coming from packet 58
  • [ ] T_CYCLOC (see Subset-026-3.6.5.1.5 a) Periodically in time.)
  • [ ] D_CYCLOC (see Subset-026-3.6.5.1.5 b) Periodically in space.)
  • [ ] M_LOC (see Subset-026-3.6.5.1.5 d) At every passage of an LRBG compliant balise group)
  • [ ] N_ITER
  • [ ] D_LOC(k) (see Subset-026-3.6.5.1.5 )
  • [ ] Q_LGTLOC(k) ( see Subset-026-3.6.5.1.5 c) When the max safe front end or min safe rear end of the train has passed a specified location.
• [ ] Packet 0 Position Report
• [ ] Packet 1 Position Report based on two balise groups

[MarcBehrens]

Additional requirement Subset-026-03.6.5.1.4 for OBU trigger to sent position reports:

• [x] a) The train reaches standstill, if applicable to the current mode. (relates to https://github.com/openETCS/modeling/issues/70)
• [ ] b) The mode changes. (relates to https://github.com/openETCS/modeling/issues/71)
• [ ] c) The driver confirms train integrity.
• [ ] d) A loss of train integrity is detected.
• [ ] e) The train passes a RBC/RBC border with its min safe rear end.
• [ ] f) The train passes a level transition border (from level 2/3 to level 0, NTC, 1) with its min safe rear end.
• [ ] g) The level changes.
• [ ] h) A communication session is successfully established.
• [ ] i) Intentionally moved.
• [ ] j) The train passes an LRBG compliant balise group (see 3.6.2.2.2), if no position report parameters are stored on-board.
• [ ] k) The train passes a RBC/RBC border with its max safe front end.

[MarcBehrens]

During start of mission

Subset-026-5.4.4.1 and Subset-026-5.4.3.1 concerning A33, A34 Subset-026-5.6.2.2 A045

relates to https://github.com/openETCS/modeling/issues/66

[MarcBehrens]

Subset-026-08

Message 136: Train Position Report Message 157: SoM Position Report

[idelatorre]

3.6.5.1.4 a) It is started with the definition of a simple Test Case that includes the following key aspects:

• One balise group
• No linking info
• Nominal direction
• Initial V_TRAIN = 5

Considering that the initial speed <> 0 km/h we do not expect any position report; however, a position report is sent including the packet 1 as soon as the inputs are received and processed.

There is an error. Operation Op_N_Iter returns true, thus triggering the sending of a report. This is wrong, as the iter packet we are providing as an input is disabled (valid flag is false).

As Christian told, In posBGs only noCoordinateSystemHasBeenAssigned is relevant (for determing whether packet 0 or 1 is used in the report). However, in the TC_1_1, noCoordinateSystemHasBeenAssigned with either true or false values has always the same behaviour: it sends the packet-1.

In addition, the following clarifications are needed:

1) to trigger the sending of the report by changing the mode (as said in 3.6.5.1.4 b). We see that the modelLevelStatus has the m_mode, m_level and m_leveltr vars but we are not sure about whether changing these values are enough to simulate a change of mode or the model needs other information.

2) Concerning the 3.6.5.1.4 c and d, which refer to 'the driver confirms train integrity' and a 'loss of train integrity is detected', we can see that train2trackStatus has the q_length var and there are 4 possible values to be assigned to the var. We do not know whether the appropriate assignment would be enough to simulate the confirmation of train integrity and loos of integrity due to it does not seem to be a trigger for sending the position report.

3) Regarding the 3.6.5.1.4 e and k, 'The train passes a RBC/RBC border with its min safe rear end' and 'The train passes a RBC/RBC border with its max safe front end'we can see that in trackInfo input the minSafeRearEndPassed(e) and maxSafeFrontEndPassed(k) would be set to true so the change made triggers the sending of the position report. However, we are not sure about what the trigger for g) 'the level changes' is. Updating the m_leveltr var located inside modelLevelStatus input would be enough?. On the other hand, is levelTransitionBorderPassed var of the trackInfo input linked to 3.6.5.1.4 f)? Because there is not a direct reference to SRS

[idelatorre]

As it was discussed in telco, some isolated operators have been verified, only internal logics can be verified

• Op_3_6_5_4_1_a: in addition to the previously reported issue another test has been executed. the train is moving with speed 5, no reach to standstill and the trigger is activated, so the test is failed.
• Op_3_6_5_4_1_b: there are situations that can not be given and which are processed as inputs. Tests coverage 100%
• Op_3_6_5_4_1_c_d: correct, Tests coverage 100%
• Op_3_6_5_4_1_e_f_h_k: correct, Tests coverage 100%
• Op_3_6_5_4_1_g: correct, Tests coverage 100%

Furthermore, another clarification is needed

• Op_3_6_5_4_1_j: We do not know how to indicate that ther are no position parameters PosRepPara because PosRepParathe data is not an operator input. In addition, we do not know how indicate that LRBG just has been passed

The input and output data of the operators are in https://github.com/openETCS/validation/tree/master/VnVUserStories/VnVUserStorySQS/05-Work/Provide%20Position%20Report%20verification

[MarcBehrens]

@christianstahl can you provide a clarification here

[christianstahl]

relevent elements of posBGs: I also check whether the LRBG is contained in the list of positioned BGs (by comapring the NID). This check is used for M_LOC (a parameter of the position report parameters) and the trigger specified in 3.6.5.1.4 j. In addition, for adding the data intp packet0/1 I need to calculate D_LRBG. To this end, I check whether the LRBG is contained in the list of positionedBG, calculate the distance D_LRBG, if the trainPosition is valid and not unknown and the LRBG is contained in the list of positionedBG. For determining whether packet0 or 1 is sent, please refer to operator op_rep0_or_rep1. It is very likely that things are more complicated than necessary or even became obsolete as the input have been changed over the past weeks numerous times.

[christianstahl]

to 1) operator op_3_6_5_1_4_b only compares the current and the last mode; operator op_3_6_5_1_4_g only campares the the current and the last level. To observe an effect at the output, however, you need to ensure that none of the other trigger or events are activated.

[christianstahl]

to 2) in case of Q_LENGTH_Train_integrity_confirmed_by_driver or Q_LENGTH_Train_integrity_lost a trigger is set and, thus, a report is sent.

[christianstahl]

to 3) see 1) what has been modeled. Whether this is sufficient from the point of view of the SRS I cannot answer. But maybe @MarcBehrens can?

[christianstahl]

@MarcBehrens @idelatorre I have fixed the problem with N_ITER. To deal with situations in which no position report parameter package (packet 58) is sent, I assume a "dummy packet 58" to be the input with variable N_ITER=0. Once a valid packet 58 is sent by the RBC, this packet with present flag=false should the input until the last element of the list has been passed. Then either a new packet 58 has to be sent by the RBC or a dummy input has to be provided. In a later step (after March), this assumption can be simplified. However, to this end I need to understand what kind of inputs this block has to expect.

[MarcBehrens]

In case of no position report parameters are sent a preset standard behavior is assumes to be applied. This can be country specific (dependent on NID_C).

Please keep in mind that N_ITER = 0 is a valid answer judging from the syntax. In this case no D_LOC (Incremental distance between locations where the train has to report its position.) and no Q_LGTLOC (Qualifier for the specified report location) is defined.

[MarcBehrens]

blocked due to SCADE license issues

[MarcBehrens]

Dear Izaskun,

is someone available to work on the formalization of your testspec?

Kind regards, Marc