Emergency brake by level chang

[Farhangi]

an emergency brake will be triggered after the level Change(Level_2 -> NTC). (@32001 m)

@JakobGartner
@T12z

[JakobGartner]

I am not sure if the EM locations are already correctly calculated

On 28 Oct 2015, at 17:37, Peyman Farhangi notifications@github.com wrote:

an emergency brake will be triggered after the level Change(Level_2 -> NTC). (@32001 m)
https://cloud.githubusercontent.com/assets/2284296/10795449/1bac8bee-7d9a-11e5-9ddd-38a08098107a.PNG
@JakobGartner https://github.com/JakobGartner
@T12z https://github.com/T12z
—
Reply to this email directly or view it on GitHub #874.

[jokaICS]

Is there really an emergency message (Msg 15/16) involved, or do we just overpass the EoA?

[JakobGartner]

I am trying to answer the same question right now—

when I see the data, the value 500000 for the EOA looks strange, as we don’t have such a value in our data, with exception of the constant that defines the NTC speed profile.

An here it might then just be a scaling error in my constant?

On 28 Oct 2015, at 18:16, Johannes Kastner notifications@github.com wrote:

Is there really an emergency message (Msg 15/16) involved, or do we just overpass the EoA?

—
Reply to this email directly or view it on GitHub #874 (comment).

[JakobGartner]

The MRSP we used for NTC was too short, hence as soon as we switched into NTC Level, we stop…

Fixed…

On 28 Oct 2015, at 18:21, Jakob j.gaertner@lea-energy.com wrote:

I am trying to answer the same question right now—

when I see the data, the value 500000 for the EOA looks strange, as we don’t have such a value in our data, with exception of the constant that defines the NTC speed profile.

An here it might then just be a scaling error in my constant?

On 28 Oct 2015, at 18:16, Johannes Kastner <notifications@github.com mailto:notifications@github.com> wrote:

Is there really an emergency message (Msg 15/16) involved, or do we just overpass the EoA?

—
Reply to this email directly or view it on GitHub #874 (comment).

[BaseliyosJacob]

Dear all,

we have here again a system switch between an ETCS Level 2 and NTC with a previoius MA for Level 2.

I see 3 riks from my point of view:

1. the MA is to short until the switch.
2. Is the MA EOA before or after the switch (transition balise) from Level 2 and NTC (@jakobgärtner)
   can you check it on the track data?
3. there is an issue between the computation of the MA in the track Atlas, Speed Suprervision and Mode and Level Management.

[JakobGartner]

There was a simple error in the workaround for NTC, which lead to the allowed speed being 0 at this location.

On 29 Oct 2015, at 11:08, Baseliyos Jacob notifications@github.com wrote:

Dear all,

we have here again a system switch between an ETCS Level 2 and NTC with a previoius MA for Level 2.

I see 3 riks from my point of view:

1. the MA is to short until the switch.
2. Is the MA EOA before or after the switch (transition balise) from Level 2 and NTC (@jakobg https://github.com/jakobGärtner)
   can you check it on the track data?
3. there is an issue between the computation of the MA in the track Atlas, Speed Suprervision and Mode and Level Management.

—
Reply to this email directly or view it on GitHub #874 (comment).

[Farhangi]

The bag is not yet fixed(emergency brake will be triggered)

And the train still runs with maximum Speed 40 km / h.

[JakobGartner]

Ok I have re-pushed the constant for NTC. If it doesn't work now its something else

Sent from my iPhone

On 29.10.2015, at 14:52, Peyman Farhangi notifications@github.com wrote:

The bag is not yet fixed(emergency brake will be triggered)

And the train still runs with maximum Speed 40 km / h.

—
Reply to this email directly or view it on GitHub.

[T12z]

By the way,
there was a discussion, whether speed profiles need some kind of end-marker, e.g. 0, 635 km/h or whatever. From SDM's point of view, profiles are always open ended and are limited by the MA. So an end-marker does not add anything, but may break things.

[JakobGartner]

So, should I

(a) leave the end- marker in
(b) replace it by 0 at the location of the EOA
(c) put the speed from the prior section
(d) do something else?

On 30 Oct 2015, at 12:45, Thorsten Schulz notifications@github.com wrote:

By the way,
there was a discussion, whether speed profiles need some kind of end-marker, e.g. 0, 635 km/h or whatever. From SDM's point of view, profiles are always open ended and are limited by the MA. So an end-marker does not add anything, but may break things.

—
Reply to this email directly or view it on GitHub #874 (comment).

[T12z]

You can (a) leave things as they are
You shall not (b) (c) generate things. In fact, a "valid" MRSP with 0 km/h may actually cause undefined behaviour.

If DMI requires some sort of End-Marker -- as long as it is past the MA, SDM should not give a continental.

From specification the MRSP-Array should only contain existing profiles (start-location + speed limit). Each profile ends at the next start-location or with the MA. It is also totally fine to pass in known profiles beyond the MA.

[JakobGartner]

OK

yes, I agree after re-reading the SRS.

The end- markers only have significance for the processing on packet- level.
On MRSP level, they are not needed anymore.

I know what to do :-) now.

On my backlog for next TA release

On 30 Oct 2015, at 13:33, Thorsten Schulz notifications@github.com wrote:

You can (a) leave things as they are
You shall not (b) (c) generate things. In fact, a "valid" MRSP with 0 km/h may actually cause undefined behaviour.

If DMI requires some sort of End-Marker -- as long as it is past the MA, SDM should not give a continental.

From specification the MRSP-Array should only contain existing profiles (start-location + speed limit). Each profile ends at the next start-location or with the MA. It is also totally fine to pass in known profiles beyond the MA.

—
Reply to this email directly or view it on GitHub #874 (comment).

[Farhangi]

Hello @JakobGartner

it looks like that the "MA sections" that are provided by TrackAtlas for SpeedSupervision, are not updated.