Utrech-Amsterdam:: Level changge not in correct position

BerndHekele commented 9 years ago

I have tested the level change on the Utrecht-Amsterdam now for some time. In my understanding of the use case, the position of the level change is not really aligned with the track.

This should be tested asap in order to have a reasonable use case.

Findings:

the second message 3 is sent after the level change has happened. In our model this results in a curious situation:

level change is requested a second time but the position where it should happen is already passed.
I will check the behaviour of the levels model and will look for a workaround i the input channel if needed..

@JakobGartner : we urgently need a stable evc model on github. I can test with some workaround in the trackatlas. Can you please push such a temporary solution or give permission to me to push my workaround. Otherwise testability for all is not available.

This issue is important but not blocking.

ghost commented 9 years ago

OK we will look too

is it still the problem with the wrong LRBG (LRBG referenced in the message against LRBG in the train position) ?

On 2015-08-29 15:47, Bernd Hekele wrote:

I have tested the level change on the Utrecht-Amsterdam now for some time. In my understanding of the use case, the position of the level change is not really aligned with the track.

This should be tested asap in order to have a reasonable use case.

Findings:

the second message 3 is sent after the level change has happened. In our model this results in a curious situation:

level change is requested a second time but the position where it should happen is already passed.

I will check the behaviour of the levels model and will look for a workaround i the input channel if needed..

@JakobGartner [1] : we urgently need a stable evc model on github. I can test with some workaround in the trackatlas. Can you please push such a temporary solution or give permission to me to push my workaround. Otherwise testability for all is not available.

This issue is important but not blocking.

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

Mairamou Haman Adji Junior Software Developer

Research Fellow

LEA RAILERGY

Links:

[1] https://github.com/JakobGartner [2] https://github.com/openETCS/modeling/issues/698

JakobGartner commented 9 years ago

do you mean the deactivation in NTC?

On 29 Aug 2015, at 16:07, Mairamou Haman Adji notifications@github.com wrote:

OK we will look too

is it still the problem with the wrong LRBG (LRBG referenced in the message against LRBG in the train position) ?

On 2015-08-29 15:47, Bernd Hekele wrote:

I have tested the level change on the Utrecht-Amsterdam now for some time. In my understanding of the use case, the position of the level change is not really aligned with the track.

This should be tested asap in order to have a reasonable use case.

Findings:

the second message 3 is sent after the level change has happened. In our model this results in a curious situation:

level change is requested a second time but the position where it should happen is already passed.

I will check the behaviour of the levels model and will look for a workaround i the input channel if needed..

@JakobGartner [1] : we urgently need a stable evc model on github. I can test with some workaround in the trackatlas. Can you please push such a temporary solution or give permission to me to push my workaround. Otherwise testability for all is not available.

This issue is important but not blocking.

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

Mairamou Haman Adji Junior Software Developer

Research Fellow

LEA RAILERGY

Links:

[1] https://github.com/JakobGartner [2] https://github.com/openETCS/modeling/issues/698 — Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/698#issuecomment-135989022.

BerndHekele commented 9 years ago

Yes - and I need in addition a bridge for the gap where the level change is done but the data from informaton filter is not in the track-atlas fo #692).

BerndHekele commented 9 years ago

@BaseliyosJacob : What is the correct behaviour for a level transition request pointing to a position in the rear of the train?

JakobGartner commented 9 years ago

I think normally the level change must not come before the MA active.

This means that

either the level module needs different inputs/ has other problem
or we need a shortcut that will maintain the NTC mode in track atlas until the MA is active

probably the latter is faster to do

On 29 Aug 2015, at 16:41, Bernd Hekele notifications@github.com wrote:

Yes - and I need in addition a bridge for the gap where the level change is done but the data from informaton filter is not in the track-atlas fo #692 https://github.com/openETCS/modeling/issues/692).

— Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/698#issuecomment-135993990.

BerndHekele commented 9 years ago

This latter discussion is not so much linked to level change as it is implemented. The question is related to show the expected behaviour in a situation where the driver did not react in the expected way.

BaseliyosJacob commented 9 years ago

Hello Bernd,

the level transition should ack request be requested as soon the train receives the packet 41.

Driver has to ack the transition
text message for ack should disappear from the dmi
level transition should be executed after defined D_LEVELTR in Packet 41

Is the explanation helpful?

BaseliyosJacob commented 9 years ago

Dear Bernd,

to understand:

Do you mean the behaviour:

when the driver ack the level transition text message in the proper time and distance?
Or when the driver doesnt ack the level transition text message in the proper time and distance?
- This behaviour is not implemented on the DMI yet!

BerndHekele commented 9 years ago

Thanks Baseliyos. The second scenario is the one I had in mind. I believe we need to show the activation of the SB here to react according to the SRS. I see Levels indicating the brake but I did not see a reaction of the EVC.

BerndHekele commented 9 years ago

I opened a new issue for the brake: #699

BaseliyosJacob commented 9 years ago

Hello Bernd,

o.k.!! The second scenario is not nominal. But, o.k.!!

If you want me to clean in the second scenario the text message from the DMI after violating the time or distance of the window according to ack the message, i need a trigger for this from the EVC. This trigger should come from the EVC because it should be supervised from e.g. Level & Mode management and can have differen national parameter.

It can be asimple flag when the D_LEVELTR in Packet 41 is passed and no reactio from the driver. Need at least the trigger in Structure DMI_Text_Message_T

BaseliyosJacob commented 9 years ago

it can be for e.g. clean_textmessage bool in the DMI_Text_Message_T. Will be not to much effort to implement it in the DMI Controller as soon as i have the trigger

BaseliyosJacob commented 9 years ago

@BerndHekele Just let me know if you decided to change the interface DMI_Text_message_T with the new trigger !! I will implement it in the DMI Controller

JakobGartner commented 9 years ago

a first fix for the behaviour during NTC is introduced clean fix to also account for message 3 delayed arrival is in work

BaseliyosJacob commented 9 years ago

@BerndHekele the behaviour for the case that the driver does not ack in the proper time or distance is according to the SRS to brake the train. Since according to the SRS the EVC assume that there is not other CCS system. And when the driver does not accept the Level 2 mode FS transition there will be no supervision. But keep in your mind that we have another case in Utrecht - Amsterdam since there is a double layer of CCS systems on the track - but i assume we will not consider the special case of Utrecht - Amsterdam!!

BaseliyosJacob commented 9 years ago

Hello Bernd,

another reason why the level transition requested twice is maybe:

the first transition has been triggered by the RBC message
the next transition has been triggered by the balise
- keep in your mind that the balise trigger is just repeating the level transition for the case that the transition has not been triggeres by the RBC message or for level 1

Maybe the balise trigger is the reason why there is a second request. But should be not considered since the first from the RBC has been accepted.

Just as a notice

BerndHekele commented 9 years ago

Hi Baseliyos, you should take your time (as a preparation for the presentation) to run the track and look at the different messages comming from the track and the reaction of the evc. If there is a strange bevaviour (like message 3 after having passed the level transition - make an error report.

The presentation needs to look quite professional in the areas where we have a show case. And wrong reaction with the driver ack is somethin that needs to be clean for such a show-case.

cu Bernd

BaseliyosJacob commented 9 years ago

@MariellePetitDoche are you at the moment aware of this issue? Can you help me to fix it since i am in charge of the DMI acknowledge.

BerndHekele commented 9 years ago

I continue to test this user story. Actual Situation:

EVC completes level transition (level 2, FS)
at position BG351 + 47 m RBC sends the MA request again (same data in the packats as seen before).
information is passed directly to TrackAtlas and Mode and Level. The requested position of the level transition is in the back of the position of the train.
I see an error in the "InformationFilter" Bypass in Level 2 which needs correction.

janWelte commented 9 years ago

All points your are listing are correct. As the level has already been switched the level transition shall be processed as already done, without any EVC reaction. Everything is absolutely fine. The only problem is that the track Utrecht-Amsterdam is not conform to the SRS as it does not satisfy "5.1.1.1 At the level transition border a balise group with an order to switch to the new level immediately shall be placed." (unchanged from 2.3 to 3.0) but since "5.10.1.5 If the message from the border balise group is not received, the level transition shall still be executed when the estimated front end passes the location given in the announcement." works, it shall still work.

This is the problem for our transmittion information, as our Level and Mode management always exspects a driver or immediate level transition.

The second RBC message is just a bit late.

BaseliyosJacob commented 9 years ago

o.k.!! Does the second trigger then triggered by the RBC message and not by the balise message?

BaseliyosJacob commented 9 years ago

Thank you very much Jan. And from my understanding - the P 41 in the balise is the border. In this case the transmission has to be procedured even the radio message P 41 has not been considered before. On the other hand. If the radio message P 41 has been concidered but the balise message P 41 has not been considered the transmission should be procedured after the D_LEVELTR in P 41. This is my understanding.

janWelte commented 9 years ago

that is the point, but just after the train is "sure" he passed the Level transition border

BerndHekele commented 9 years ago

Solution available.

openETCS / modeling