search

openETCS / modeling

WP3 Top Level Project: to cover all tasks related with modeling
31 stars 42 forks source link

US-Track Model scope "proof of concept" Utrecht - Amsterdam #495

Open BaseliyosJacob opened 9 years ago

BaseliyosJacob commented 9 years ago

For the proof of concept of the Utrecht - Amsterdam line we need a track model, as defined in the scope of the "proof of concept" (https://github.com/openETCS/modeling/tree/master/User%20Stories/Utrecht%20-%20Amsterdam%20Track%20Example), for testing of the "proof of concept" ETCS Onboard Unit.

JakobGartner commented 9 years ago

This is done for the first two sections which are representative for the entire track.

Jakob

On 27.06.2015, at 08:49, Baseliyos Jacob notifications@github.com wrote:

For the proof of concept of the Utrecht - Amsterdam line we need a track model, as defined in the scope of the "proof of concept" ( https://github.com/openETCS/modeling/tree/master/User%20Stories/Utrecht%20-%20Amsterdam%20Track%20Example), for testing of the "proof of concept" ETCS Onboard Unit.

— Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/495.

BaseliyosJacob commented 9 years ago

Dear Jakob,

thank you very much for the information.

Great news For the proof of concept we need the whole scope as defined of the track. Can you estimate a date for the delivering the whole scope of the selected track?

Thank you very much

JakobGartner commented 9 years ago
  1. The entire track L2 is done as far as balise messages and packets are concerned,
  2. For RBC messages, the 1st two sections are done. As now all the basic functions in TrackMessages and InfraLib are done, we need one more week for the rest
JakobGartner commented 9 years ago

The track model is DONE.

Some pseudo- issues were raised (NID_LRBG is often not the same as the current LRBG of the train, which is just a reflection of the reality seen in the JRU data).

Other issues raised in this context refer rather to #497

BaseliyosJacob commented 9 years ago
BaseliyosJacob commented 9 years ago

Scope of the track is complete in working status

BaseliyosJacob commented 9 years ago

Issue #559 added

ghost commented 9 years ago

I have competed a first draft of the documentation for the test track

see https://github.com/openETCS/modeling/blob/master/model/Scade/System/TracksideDynamicModel/TestTracks/UtrechtAmsterdam_Documentation/AmsterdamUtrecht.pdf

JakobGartner commented 8 years ago

I am pushing the model that @mairamou has built, after some tests and checks.

The new track model covers, for now, US13.

@Rainer-Lampatzer : you need to provide one additional trigger for RBC messages shortly after LRBG 359. You must however make sure that you have two distinct sets of triggers (or another way to make sure you send the right trigger for each track.)

@BerndHekele : The model has one additional input "SelectTrack" where you can choose if you want to drive on a track for US 1-12 or a track for US 13-16 (the type is self-explaining, and there is a set of constants to well define the selection criterion). Probably it makes sense to somehow send this info also to the RBC so they can use the same simulation setting.

The new model is contained in a package US_integration_Novermber and has exactly the same structure as before.

Mairamou is extending the track model document to reflect the additional functionality and we have the other US in the pipeline

jokaICS commented 8 years ago

@JakobGartner I see that US_Integration_June and US_Integration_November use the same node for the balise messages (Amsterdam_Utrecht_Lijn1_balises); so the the difference between US 1-12 and US 13-16 are only the radio messages, correct? Or are the balise messages for US 13-16 located "after" the normal track? (I'm asking since I want to create a track file from the new track model; the file for US 1-12 is generated by "driving" through posotion 0.0m -- 33.000m)

JakobGartner commented 8 years ago

Both scenarios use the same track.

There is a switch to select which one to use

So, for each track we start from the same point and then we encounter different RBC messages

On 10 Nov 2015, at 20:57, Johannes Kastner notifications@github.com wrote:

@JakobGartner https://github.com/JakobGartner I see that US_Integration_June and US_Integration_November use the same node for the balise messages (Amsterdam_Utrecht_Lijn1_balises); so the the difference between US 1-12 and US 13-16 are only the radio messages, correct? Or are the balise messages for US 13-16 located "after" the normal track? (I'm asking since I want to create a track file from the new track model; the file for US 1-12 is generated by "driving" through posotion 0.0m -- 33.000m)

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

jokaICS commented 8 years ago

I've added the track file for US13-16 to test/EnvSim/track/.

@Rainer-Lampatzer could you please start verification (and maybe try running it with the standalone testbench)?

Rainer-Lampatzer commented 8 years ago

@JakobGartner

bitte Rückruf ....

Rainer-Lampatzer commented 8 years ago

@JakobGartner

for the ease of verification, please inform me about the location of the events. thanks in advance.

JakobGartner commented 8 years ago

There is only one new location added for now:

A message 3 at 30.0 m after LRBG 359

The other locations remain untouched for now. Additional locations will be added per US

In general, when you look into the models, the location is already visible from the name of the Send… functions.

On 11 Nov 2015, at 18:06, Rainer Lampatzer notifications@github.com wrote:

@JakobGartner https://github.com/JakobGartner please inform me about the location of the events. thanks in advance.

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

jokaICS commented 8 years ago

@JakobGartner it shouldn't be a problem, if we always trigger all messages, regardless of the UserStory we're in, correct (or to put it another way: we don't need to differentiate between the user stories in the user wrapper, since it's already done in the track lib)?

JakobGartner commented 8 years ago

Yes

since we restructured the data (now) on the trackside, this is transparent to you.

On 12 Nov 2015, at 09:44, Johannes Kastner notifications@github.com wrote:

@JakobGartner https://github.com/JakobGartner it shouldn't be a problem, if we always trigger all messages, regardless of the UserStory we're in, correct (or to put it another way: we don't need to differentiate between the user stories in the user wrapper, since it's already done in the track lib)?

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

Rainer-Lampatzer commented 8 years ago

RBC has now been updated to fire the trigger 359 00 0300.

There must be another problem: At ca. 4250 m,the train begins to emergency brake with an inplausibly high deceleration.

suddenbrakeinplausibledeceleration

From then on, it is possible to proceed with max. 13 kmph for several hundret meters. After these several hundret meters, any try to proceed at any speed ends up with an emergency brake.

ghost commented 8 years ago

Modular track model:

We need additional RBC triggers:

When passing LRBG 100 (close to TrainPos = 300.0) When passing LRBG 200 (close to TrainPos = 800.0)

We have done a lot of calculations in order to achieve linking consistency and real gradient data, please test!

jokaICS commented 8 years ago

you should now be able to go directly to the end of the track

@mairamou , @JakobGartner: maybe we should have a short GoTo where you can explain the modular track model? I have no idea what "going directly to the end of the track" means :-) do we need to adjust the train position?

JakobGartner commented 8 years ago

We can have a Gotomeeting

No the positioning on the track is transparent

It means that you can drive on any section of the track without having to pass the ones before

At the moment we only pushed sheet 14.

On 17.11.2015, at 21:51, Johannes Kastner notifications@github.com wrote:

you should now be able to go directly to the end of the track

@mairamou , @JakobGartner: maybe we should have a short GoTo where you can explain the modular track model? I have no idea what "going directly to the end of the track" means :-) do we need to adjust the train position?

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

UweSteinkeFromSiemens commented 8 years ago

I'm also interested in how to use this. Perhaps you should more plan to disseminate good things ...

jokaICS commented 8 years ago

@mairamou I'm a little bit confused: we now have US_Integration_November::Amsterdam_Utrecht and US_Integration_November::Amsterdam_Utrecht_US. Which is the right one (or do we need both)? I would prefer having a single top-level operator which allows switching the track via the TrackType enum.

ghost commented 8 years ago

Hmm

the top level is US_Integration_November::Amsterdam_Utrecht-

this gives you that: having a single top-level operator which allows switching the track via the TrackType enum.

On 2015-11-18 10:12, Johannes Kastner wrote:

@mairamou [1] I'm a little bit confused: we now have US_Integration_November::Amsterdam_Utrecht and US_Integration_November::Amsterdam_Utrecht_US. Which is the right one (or do we need both)? I would prefer having a single top-level operator which allows switching the track via the TrackType enum.

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

Links:

[1] https://github.com/mairamou [2] https://github.com/openETCS/modeling/issues/495#issuecomment-157651385

jokaICS commented 8 years ago

OK, so US_Integration_November::Amsterdam_Utrecht_US is no longer needed and we can remove it?

ghost commented 8 years ago

this is a sub function of the higher level function.

it can be replaced by the top level function.

This will introduce (step by step as we are releasing them one after the other) the modular track sections

TrackType will also be further extended

On 2015-11-18 11:06, Johannes Kastner wrote:

OK, so US_Integration_November::Amsterdam_Utrecht_US is no longer needed and we can remove it?

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

Links:

[1] https://github.com/openETCS/modeling/issues/495#issuecomment-157664488

jokaICS commented 8 years ago

Ah, I see, thanks. Maybe you could mark all other as private or move them to a sub-package to avoid confusion?

ghost commented 8 years ago

yes, this is done but not pushed because I followed the rule to not break the integration model...

As soon as Bernd has adopted the new top level model I will push the update

On 2015-11-18 11:17, Johannes Kastner wrote:

Ah, I see, thanks. Maybe you could mark all other as private or move them to a sub-package to avoid confusion?

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

Links:

[1] https://github.com/openETCS/modeling/issues/495#issuecomment-157669197

jokaICS commented 8 years ago

Another question regarding Sheet14: can you give me start and end of the Sheet14 track in absolute coordinates (train position). I assume start is @0m; how long is this track?

ghost commented 8 years ago

The "init track" is 1000m long and covers train position 0-1000m

the sheet 14 is 3113m long and covers train position 1000-4113m

the total track is hence 4113m long

the model transparently maps train position to the coordinates in the local coordinate system of the track sections (=engineering locations)

On 2015-11-18 11:28, Johannes Kastner wrote:

Another question regarding Sheet14: can you give me start and end of the Sheet14 track in absolute coordinates (train position). I assume start is @0m [1]; how long is this track?

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

Links:

[1] https://github.com/0m [2] https://github.com/openETCS/modeling/issues/495#issuecomment-157672399

jokaICS commented 8 years ago

Great, thanks!

@Rainer-Lampatzer the Sheet14 track is now available at test/EnvSim/track/Sheet14.trk

jokaICS commented 8 years ago

Hmm, after driving on Sheet14_only and seeing some funny behavior of the EVC / DMI (at one point, I had to acknowledge "Entering TR", but was allowed to drive on at 100 km/h :) -- what's Sheet14_only supposed to do/ provide (i.e. what's the use case)?

ghost commented 8 years ago

yes I just stumbled over something, too.

Sheet 14 is supposed to contain the level transition back to NTC, but at the P41 is sent before sheet 14 (and I forgot to put it into the init track) this doesn't happen.

Will fix

On 2015-11-18 13:46, Johannes Kastner wrote:

Hmm, after driving on Sheet14_only and seeing some funny behavior of the EVC / DMI (at one point, I had to acknowledge "Entering TR", but was allowed to drive on at 100 km/h :) -- what's Sheet14_only supposed to do/ provide (i.e. what's the use case)?

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

Links:

[1] https://github.com/openETCS/modeling/issues/495#issuecomment-157701459

ghost commented 8 years ago

the LTR issue is corrected

(will be pushed by @jakobgartner for technical reasons)

On 2015-11-18 13:46, Johannes Kastner wrote:

Hmm, after driving on Sheet14_only and seeing some funny behavior of the EVC / DMI (at one point, I had to acknowledge "Entering TR", but was allowed to drive on at 100 km/h :) -- what's Sheet14_only supposed to do/ provide (i.e. what's the use case)?

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

Links:

[1] https://github.com/openETCS/modeling/issues/495#issuecomment-157701459