LevelAndMode Input Management: Scaling not in use in packet 80

[BerndHekele]

Hi Marielle, the distance operator is not converted to internal distance presentation when working with packet 80:

Do you still have access to Scade?

kr. Bernd

[MariellePetitDoche]

Yes, i will have a look this afternoon.

[MariellePetitDoche]

Correction proposed for P80, P138 and P139

[BerndHekele]

Hi Marielle, thanks for the quick correction. I see another problem in Modes: In Input TrackManagement a wrong index is used (1 instead of 0:

[MariellePetitDoche]

For this problem there is something to clarify in the specification : P80 can contain several modes profile (how many ?). But when we need to use the information to compute mode, it is never said that the informations in the first place of the list in P80.

We can also imagine that information for LS and OS are both available in P80. I haven't found sufficient information in SRS for this.

Do you have example of P80 ?

[BerndHekele]

I have no such example in my hands - maybe Baseliyos can help? @BaseliyosJacob There is several solutions possible, e.g., a sequence of such elements. Can you show me in the SRS where this function is defined?

Can we assume for the time being we take the first element (=0) to be able to progress.

I found a second smaller issue in Librairies:Mode_ProfileCaöculations. Theassume the comparision needs to be corrected?

[MariellePetitDoche]

We can assume to take the first element, as is surely not correct.

I do not understood what is the second issue...

[BerndHekele]

The comparision compares actual speed with max speed in this mode given by the mode transition element. It makes only sense if you allow the transition to happen if speed is less then allowed. From a conceptual point I'm not sure whether Modes should do this comparision - but I don't want to start this discussion now.

[MariellePetitDoche]

In chapter 5 it is clearly explain that before to allow to switch to a mode with mode profile (SH, OS or LS) you have to check that the train is under the ceiling speed.

see for example fig 23 in chapter 5 and req 5.19.3.2

[BerndHekele]

That is fine. Regarding the second issue, I think I made an error in analysis and will updae you after some additional testing.

[MariellePetitDoche]

I have made the correction for a quick availability of software.

However it can be interesting not to go to quickly on such an issue as you can drawn interresting conclusion on the choice of modeling notation: One of the added value of modeling or formal method used for design, is to detect (thanks to design, simulation as you do,, test, proof or other technics) inconsistencies or lacks in an informal specification, which can sometimes be covered by designed choices. Here we have typically such an example, we have selected the simple solution, but this can be discussed.

[BerndHekele]

This correction is working now - thanks for your support. We still have a Problem: Mode switches before the end of the Window as soon as the Driver Sends Ack.

[BaseliyosJacob]

Hello Bernd,

is this screenshot of a Package 80 within the MA for Level Change from FS to OS helpful??

[MariellePetitDoche]

@BerndHekele

Yes it changes immediately and this can be surprising, but it is how it is describe in SRS §5.9.3.6, fig 5 and fig 6 (and same for LS §5.19.3.6, fig 23 and 24 and SH §5.7.3.5 and fig4).

Indeed I understand it as this : before to request ack from driver, conditions on speed and position have been checked, if the driver acknoledges he is ready to take in charge the supervision.

Do you have another specification ?

[BerndHekele]

Fine. Thanks. I don't see any other wrong behaviour and close the issue.