Calculate Train Position: Remarks to Review of "openETCS Determine Train Location Procedure"

[UweSteinkeFromSiemens]

Thank's a lot for the review. This issue is for discussing the review findings of https://github.com/openETCS/validation/blob/master/VnVUserStories/VnVUserStoryDLR/04-Results/AU_TS_ReviewDetTrainLocProc140905_01.pdf which relates to #227

• [ ] 1.3.1, l 38: “expectation window” is not a term of Subset-26-3.6.
• [ ] 1.3.1, l 41 - 47: Subset-26-3.4.4.4.3.2: *“The interval between the outer limits to accept the balise group defines the expectation window” Subset-26-3.6.4.2: "The confidence interval to the train position shall refer to the distance to the LRBG and shall take into account
  • On-board over-reading amount and under-reading amount (odometer accuracy plus the error in detection of the balise group location reference)
  • The location accuracy of the LRBG" *
• Subset-26-3.4.4.4.3, Subset-26-3.4.4.4.3.1 and Subset-26-3.4.4.4.3.2 imply the inaccuracies from BG location, balise antenna and – without mentioning it directly – odometry (how else could the location be determined?). Subset-26-3.6.4.2 is considering location, odometer and BG detection inaccuracies. Therefore, “expectation window” and “confidence interval” seem not clearly defined without ambiguity. I guess, if both terms would have non-ambigous definitions, they would have been given in the spec. Fortunately, the train sees only the superposition of incaccuracies, so the differentiation between them is not needed practically. It simply calculates an overall “expectation window” comprising the inaccuracies from BG location, odometer and BG detection.
• [ ] 1.3.2, l 48 – 54: The SRS approach of switching between different coordinate systems with every new LRBG or unlinked BG was the reason to transform this into one unique OBU coordinate system kept stable through the whole mission. Of course, this is a design decision, due to the experience that navigation in a dependable coordinate system is easier to maintain than if it would be floating around with the current LRBG. 3.6.4.3 seems misleading, since it suggests that locations change dependant with LRBG switches. But switching the LRBG does not move the train und therefore does not change its position at all.
• [ ] 1.3.2, l 53 – 54: “The SRS does not describe how to handle train positioning without having a last BG reference”: One more reason, to integrate the SRS requirement into one consistent positioning concept.
• [ ] 1.3.4, l 59 – 66: That the SRS considers only the train position as inaccurate and all other locations as exact, is an issue of the perspective and the reference system. The SRS does not override mathematical relationships, and therefore replacing the SRS perspective by mathematic calculations is feasible. Especially, since the SRS itself avoids formal mathematical calculations, it deliberately creates freedom for interpretations.
• [ ] 1.3.5, l 67 – 70: I agree. The inaccuracies are not mentioned again. The calculations have to be applied with all inaccuries taken into account.
• [ ] 1.3.5, l 73 – 74: If the confidence interval of the train only relates to the accuracy of the current LRBG, it would change with the current LRBG. This is obviously nonsense, because the switch between BGs does not affect the location range, where the train expects to find the next BG. Otherwise, the switch between BGs would move the train (or the BGs).
• [ ] 1.3.6, l 83 – 84: I agree: Omitting the location accuracy national and the default value, is a deficit.
• [ ] 1.3.7, l 92 – 95: See remarks to 1.3.1, l 41 – 47 above. Unfortunately “expectation window” is not used nor specified in Subset-26-3.6, so I created the term for my own.
• [ ] 1.3.7, l 110 – 118: Regardless which equations are applied for the calculations, their correctness and applicability have to be shown.
• [ ] 1.3.9, l 120 – 124: This is an improvement, which might not be required but leads to better accuracies. I don’t expect it to be forbidden.
• [ ] 1.3.10, l 128 – 134: I agree. The effect is – different from what the SRS suggests – not dependent on the current LRBG, but on each linked BG and occurs when passing theses BGs. I understand the LRBG as a common location reference between OBU and RBC negotiated between both. The (temporary) role of a linked BG to be the current LRBG does not affect the train position and location of track events in front of the train at all. Otherwise, the train position would be dependent on the communication between OBU and RBC. Without an OBU-RBC communication, there is no LBRG, but all the linked and unlinked BGs. Correct?
• [ ] 1.4, l 135 – 140: The induction of the OBU coordinate system and the appropriate calculation algorithms and equations must not lead to a (different) behaviour and accuracies not covered by the SRS. This has to be proven.
• [ ] 1.4, l 141 – 158: I agree.

  Postscriptum:

While implementing the function “CalculateTrainPosition” during the past months, applying the equations of chapter 2.1, 2.2, 2.3 and 5.5 (dnom, dmin, dmax only) consequently throughout the design turned to be appropriate and sufficient.

@BerndGonska , @MarcBehrens @janWelte

[UweSteinkeFromSiemens]

The content of https://github.com/openETCS/SRS-Analysis/blob/master/System%20Analysis/WorkingRepository/Group4/SUBSET_26_3-6/DetermineTrainLocationProcedures.docx has been condensed to what was used in the SCADE implementation of the CalculateTrainPosition function.