Linking consistency errors on track

[UweSteinkeFromSiemens]

The following linking consistency errors occur while traveling along the track:

• BG 366: linkedBGMissed (= not found until the end of the expectation window)
• BG 365: passedBG_foundNotWhereExpected
• BG 366: passedBG_foundNotWhereExpected
• BG 365: linkedBGMissed (= not found until the end of the expectation window)
• BG 341: linkedBGMissed (= not found until the end of the expectation window)
• BG 341: passedBG_foundNotWhereExpected
• BG 370: linkedBGMissed (= not found until the end of the expectation window)
• BG 370: passedBG_foundNotWhereExpected
• BG 371: linkedBGMissed (= not found until the end of the expectation window)
• BG 371: passedBG_foundNotWhereExpected
• BG 372: linkedBGMissed (= not found until the end of the expectation window)
• BG 372: passedBG_foundNotWhereExpected
• BG 373: linkedBGMissed (= not found until the end of the expectation window)
• BG 373: passedBG_foundNotWhereExpected
• BG 374: passed, but not announced (ok, if intended)

I stop here, since the track layout from the shown range on needs readjustment.

[BerndHekele]

Hi Uwe, I did not get any "eerors" from your function when passing these balises. How is this possible?

[BerndHekele]

I now also see these errors. Can you please have a look at this problem: @JakobGartner

[JakobGartner]

@Rainer-Lampatzer has pointed me to the possible source of the error: In US_13, there was a lazy copy and paste error which made that the 3rd MA (which actually shortens the EOA) came with the wrong NID_LRBG.

Let me know if a problem persists

[BerndHekele]

We are driving US1-12 and the problem is still open. I see two problems

1. BGs 370 and 371 are in wrong sequence in the linking data.
2. calcTrainPosition stays confused if a wrong balise has been passed. The track:

And linking:

[BerndHekele]

One additional remark: I dont see any problems in the new track at balises before 341.

[JakobGartner]

Lets be precise about OLD and NEW OLD: US1-12 NEW: US13-16

I have re-checked the data defined in the track model for US1-12 and the data are defined as follows:

I don't really understand how they can get inverted.

[jokaICS]

Hmm, could this be due to an issue with q_linkorientation? BG370 and BG372 are passed in nominal direction, whereas BG371 and 374 are passed in reverse direction.

[BerndHekele]

Update on Statement regarding BG 351: If I run the model with optimisation level 1 I get the "missed" error at position (nominal) 361726.

[BerndHekele]

Data received at LRBG 362:

• element 367 is twice in the input. 370 and 371 are in correct order
• BGs at this position have gaps between 367 and 341 are missing BGs.:

[JakobGartner]

These data differ from the ones defined on the track.

• either we miss them during the train driving along the track (which could be linked to the triggering mechanism of the balises, but would not explain the double- 367 which should be filtered out at the front end of the EVC)
• or the filter does something
• or train position mixes up something

On 13 Nov 2015, at 15:01, Bernd Hekele notifications@github.com wrote:

Data received at LRBG 364:

element 367 is twice in the input. 370 and 371 are in correct order https://cloud.githubusercontent.com/assets/3288918/11147488/89ed43d6-8a16-11e5-99a5-d4fb82dc9cae.png BGs at this position have gaps between 367 and 341 are missing BGs.: https://cloud.githubusercontent.com/assets/3288918/11147584/3d89dcba-8a17-11e5-974c-19d2daca3622.png — Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/911#issuecomment-156438160.

[BerndHekele]

The famouse filter is not involved in this function. We are talking about elements of linking data at LRBG 362.

[JakobGartner]

OK, you wrote 364

indeed there is a problem with P5 at 363, will check and correct ASAP

On 13 Nov 2015, at 15:09, Bernd Hekele notifications@github.com wrote:

The famouse filter is not involved in this function. We are talking about elements of linking data at LRBG 362.

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

[BerndHekele]

I now reached LRBG 364. Obviously, the incorrect data at LRBG 362 results in a wrong linking list which is nice cause we can reproduce the problem.:

The data received in P5 is ok:

[BerndHekele]

I was confused with this extra information at LRBG 363. I did not expect the whole data being repeated.

[JakobGartner]

yes.

this is how it is on the track.

the copy/paste error that lead top double BG367 and other problems is fixed

On 13 Nov 2015, at 15:14, Bernd Hekele notifications@github.com wrote:

I was confused with this extra information at LRBG 363. I did not expect the whole data being repeated.

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

[BerndHekele]

I'm a bit nervouse about the different behaviour at balise 351. here, we had an impact due to different code generator options. Are you sure information is correct at this position?

[BerndHekele]

We have another problem at 381 - again, the orer is incorrect (381, 382). I'm now checking the data defined before this position. At LRBG371 the last element confuses me: Same situation at LRBG 364 - last element seems to be incomplete.

[JakobGartner]

I will check on 381

on 371, indeed the value is 0 in the JRU data.

I will see what to do:

• remove
• or, reverse engineer the data from other infos on the track

On 13 Nov 2015, at 16:30, Bernd Hekele notifications@github.com wrote:

We have another problem at 381 - again, the orer is incorrect (381, 382). I'm now checking the data defined before this position. At LRBG371 the last element confuses me: https://cloud.githubusercontent.com/assets/3288918/11149454/21965fc2-8a23-11e5-9816-ace44989c871.png Same situation at LRBG 364 - last element seems to be incomplete.

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

[BerndHekele]

In principle 0 is valid as a BG.

[BerndHekele]

I'm now at LRBG 364. The data from track look fine, but the BGs have a gap (BG 374 is missing in the list: Uwe's list:

Input from track:

[JakobGartner]

[BerndHekele]

Next Update at LRBG 42600371. Now the data get's confused: BGs:

Again, the input look nice in this situation:

[BerndHekele]

I will ask Uwe for Support on this issue on Monday...

[BerndHekele]

Another positioning Error in the rear part of the track (BG438)

[JakobGartner]

fixed

On 13 Nov 2015, at 18:05, Bernd Hekele notifications@github.com wrote:

Another positioning Error in the rear part of the track (BG438) https://cloud.githubusercontent.com/assets/3288918/11152118/0c573f88-8a31-11e5-88f6-8d5079c6d24f.png — Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/911#issuecomment-156489247.

[BerndHekele]

@UweSteinkeFromSiemens : In this place the wrong sequence is seen for the first time after BG 364:

[BerndHekele]

Looking into the model indexOfBG_onTrack_itr you get the following logic:

which logic I don't quite understand (which location is compared here?

[UweSteinkeFromSiemens]

Dear Bernd, I'm on a business trip to Munich during the next week. Unfortunately, I will be offline completely on Monday and Tuesday. The next opportunity for me to analyze the problem is on Wednesday (perhaps at the Völckerstr. 5) or on Thursday.

[BerndHekele]

Dear Uwe, I'm fine with your proposal. I have the feelinmg the problem is triggered by some data inconsistency in the linking data which I did not find so far. I will try to digg a bit deaper to prepare your stop in Munich Völckerstrasse.

[UweSteinkeFromSiemens]

Yes, that' also my Impression. The inconsistency in the linking data has to be fixed anyway. The problem to maintain the correct order of BGs in inconsistent linking scenarios can be fixed independently. By the way, the latter is not so easy and typically requires a safety analysis before to answer questions of required robustness against misplaced BGs, multiple BGs with the same ID, linking inconsistencies, multiple announcements of the same BG at different locations, wrong ordering etc. This seems to be more than what is specified regarding linking consistency in SRS.

[ghost]

For the MA and the related P005 received at BG364, I have done an analysis:

• In the JRU data, the NID_BG the segment 29 is referring to has the value NID_BG=0
• I did a consistency check and incremental calculation of the linked BGs from LRBG 364
• I cross checked with the actual bails positions as corrected based on the linking data (and validated since long)

--> segment 29 of JRU data in P005 received with NID_LRBG 426,364 yields to the corrected position of BG 393.

----> I have corrected the incomplete linking data.

Conclusion. It seems that the JRU data are illustrating a track which is was not fully engineered and validated during the travel. I will document that in my track model doc.

I have pushed the solution

I can not at all reproduce any of the other problems on the track model level. The track model is consistent with the JRU data as far as linking is concerned. (which does not totally exclude single errors, but for example there is nowhere a switch of BG 370 and BG371.

[BerndHekele]

@UweSteinkeFromSiemens : Dear Uwe, I had a closer look at the way the linking information is processed. I currently have the following understanding of the situation (based on the attached symptoms):

• we pass BG 362
• we receive Linking information relative to LRBG 362 - list gets updated.
• we pass BG 363
  • The location of the BGs in the past get adjusted with the new information?
• we receive linking information again relative to LRBG 362
  • now the routines to find BGs in the list get confused by the changed location information.

[UweSteinkeFromSiemens]

@BerndHekele : That's great, thank's a lot for your analysis.

Announcing a BG already passed in rear of the train is completely useless, but without no doubt calculateTrainPosition should be robust against it. When implementing I was not aware of it. I will fix it asap, when I get a valuable internet access.
In fact, as I stated above, it should be clarified as part of a later follow-up project, which other useless or weird scenarios must be taken into account.

[JakobGartner]

This seems to be a very standard scenario, as ALL the MAs we receive on the track come AFTER passing the LRBG.

It seems also (I have seen that from looking at the unused JRU data we have) that only specific BGs are used as LRBGs. They are all somehow related to specific features on the track (points, signals).

I had the same issue with the other track related data, that was part of my 1st learning curve in TrackAtlas.

There is a 2-step processing in TrackAtlas:

• 1st, sort out the data relative to the LRBG (wherever the train is)
• 2nd, relate the data to the train-

On 16 Nov 2015, at 19:08, Uwe Steinke notifications@github.com wrote:

@BerndHekele https://github.com/BerndHekele : That's great, thank's a lot for your analysis.

Announcing a BG already passed in rear of the train is completely useless, but without no doubt calculateTrainPosition should be robust against it. When implementing I was not aware of it. I will fix it asap, when I get a valuable internet access.

In fact, as I stated above, it should be clarified as part of a later follow-up project, which other useless or weird scenarios must be taken into account.

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

[UweSteinkeFromSiemens]

Dear @JakobGartner, the situation for MAs is comprehensible different: A LRBG must have been passed by the train and reported to the RBC, before it is allowed to be used by the RBC as a reference BG. In contrast, announcing a BG already been passed at most may reduce location uncertainty a little, but is otherwise useless. Since this behaviour is not specified - as far a I know - we are about to investigate the system by observation ...

[JakobGartner]

the Packet 5 is sent as part of a Message 3, consistently.

That is why I said “The MAs are received…”

The first MA (with linking data) is sent before the level transition, then again at the level transition with identical data; but in both cases after passing the ref LRBG

Yes, we are discovering the track by driving over it :-) and encounter many nice surprises

On 16 Nov 2015, at 20:09, Uwe Steinke notifications@github.com wrote:

Dear @JakobGartner https://github.com/JakobGartner, the situation for MAs is comprehensible different: A LRBG must have been passed by the train and reported to the RBC, before it is allowed to be used by the RBC as a reference BG. In contrast, announcing a BG already been passed at most may reduce location uncertainty a little, but is otherwise useless. Since this behaviour is not specified - as far a I know - we are about to investigate the system by observation ...

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

[UweSteinkeFromSiemens]

This issue is followed up by #926, #927 and can be closed from my point of view.