Use Case 12: End of Mission in Level NTC and Mode SN

[BaseliyosJacob]

Dear all,

find the Sequence Diagramm for this US on:

https://github.com/openETCS/modeling/blob/master/User%20Stories/User%20Story%2012.pdf

[BaseliyosJacob]

• Analysis
• Modelling
• Documentation
• Handover to V&V
• Approval from V&V

[Rainer-Lampatzer]

Request for clarification:

End of mission is initiated by the driver by transisiton to SB mode, see Chapter 5.5.2.1. In order to avoid even more complex situations, special cases considered in Chapters 5.5.2.2 and 5.5.2.3 should not be considered here.
(For information: No matter if the previous mode was FS or NTC, it is the same condition that causes the transition to SB; see Chapter 4.6.3 Condition 28)

Chapter 5.5.3.1.3 writes that the termination of the Communication session is part of the End of mission:
Step 1 - EVC internal
Step 2 - The end of mission shall be reported to the RBC by means of the message “End of Mission”.
Step 3 - The RBC shall request to terminate the communication session.
Step 4 - The ERTMS/ETCS on-board equipment shall terminate the communication session

The problem in User story 12: Step 2 is missing. RBC is not triggered to request to terminate the communication session.
The request to terminate the communication session at an arbitrary time would lead to a possible error: If EVC has not already reported the end of mission, then EVC would ignore the request.

So please consider to insert an arrow from OBU to RBC at the beginning, labeled with "Message 150 (End of Mission) + Packet 0 (Position Report)

[BaseliyosJacob]

Dear Rainer,

thank you very much for the feedback. I have correct it. Can you please check it?

Thank you very much

[Rainer-Lampatzer]

Dear Baselios,

Thank you very much.

@? (the collegue responsible for the scenario):

In order to reduce complexity, please choose a location with a directed BG, so that packet 0 can be used, and not packet 1.

Thanx a lot in advance,

Rainer

Ok

I am responsible for the track model for the user stories.

I will consider your request but we need to ask @Baseliyos how close we
must stay to the reality of the Amsterdam Utrecht track.

I will analyze and come back to you if u see a conflict between those
goals

(my GitHub tag is @Mairamou)

On 2015-10-21 13:22, Rainer Lampatzer wrote:

Dear Baselios,

Thank you very much.

@? (the collegue responsible for the scenario):

In order to reduce complexity, please choose a location with a directed BG, so that packet 0 can be used, and not packet 1.

Thanx a lot in advance,

Reply to this email directly or view it on GitHub [1].

Links:

[1]
#251 (comment)

[BaseliyosJacob]

Dear Mairamou,

thank you very much. I understand that you are in responsibility of the track sceanrio and @BerndHekele is assigned as technical owner of the US.

Coming to your question: lets keep it real but simple. We should keep the distance and events as short as possible since we are simulating a non-nonimal situation here.