Calculate Train Position: Conclusions from Train Positioning Closing Session

[UweSteinkeFromSiemens]

This issue refers to #227 and https://github.com/openETCS/validation/blob/master/MinutesOfMeeting/141028_Verification_Closing_Session_Train_Positioning/A-D-VerfRprt-Train-Position-141028-V01.pdf.

The intention is to structure the cooperation for fixing the conclusions from the report:

Differences within the simulation and implementation has been detected and the two approaches have to be merged (Jan: Specify, Uwe: Implement)

• [x] 1. synchronize on using the inaccuracies of the BG passed or just of the last BG and the 1st BG (Uwe and Jan Welvaarts)
• [x] 2. backwards calculation of inaccuracies need to be synchronized (Uwe, Jan)
• [x] 3. agree on the output data (Uwe, Jan Welvaarts, Vincent)
• [x] 4. synchronize data structure for balise storage and storage of other trackside related information
• [x] 5. agree on the input data (Uwe, Jan Welvaarts, Vincent)
• [x] 6. integer arithmetic only on the model (design decision of WP3)
• [x] 7. resolution of train position in cm (design decision of WP3)
• [x] 8. Inaccuracy of the Odometer is agreed to be taken into account (Uwe)
• [x] 9. Center Detection accuracy is agreed to be taken into account (Uwe)
• [x] 10.define national values to be used (Jan Welvaarts)
• [x] 11. national values can also change at some point on track (Uwe)
• [x] 12. a as common reference for saving the data the start-up position of the OBU is taken
• [x] 13. rules have to be implemented correctly
• [x] 14. Q_LOCACC will be made dependant on the national values and on the linking information (Uwe, Vincent)
• [x] 15. Implement distance calculation to track objects, other than balises (Uwe)

For contribution: @JanWelvaarts , @VNuhaan , cc: @janWelte , @MarcBehrens , @JakobGartner

[UweSteinkeFromSiemens]

To 3. + 5.: The input and output data of the implementation are specified in https://github.com/openETCS/modeling/blob/master/model/Scade/System/ObuFunctions/ManageLocationRelatedInformation/TrainPosition/CalculateTrainPosition/GeneratedDocuments/CalculateTrainPosition_Interface.pdf.

[UweSteinkeFromSiemens]

To 1., 2., 8., 9.,12 and #227:

Matching the calculation algorithms:

The two existing train position calculation algorithms from @JanWelvaarts and @UweSteinkeFromSiemens have been matched in https://github.com/openETCS/modeling/blob/6b1ca72f3f6ec2ba77b5ad4216ed262b0eb0ce2c/openETCS%20ArchitectureAndDesign/Work%20Groups/Group%204/CalculateTrainPosition/Calculations/MatchingTrainPositionCalculationAlgorithms.pdf

[MarcBehrens]

going through the open points at the small cluster meeting together with @UweSteinkeFromSiemens

4. concerning the data structures it is defined inside the 2nd/ 3rd iteration. Please adjust the design and the model here for the upcoming iteration @UweSteinkeFromSiemens @BaseliyosJacob
5. the national values are not implemented inside scade for the first iteration (Design decision)
6. Question: Is the reason behind this to avoid the floating point? Is fixed point explicitly ruled out? Please clarify the requirements here! @BerndHekele
7. see 6., after discussion the need of higher resolution the proof of the sufficiency is needed here. Inside implementation and design - does this refer to the messages transferred or the internal calculation, and refers to 6. Please provide clarification on design side.
8. Constraints on the inaccuracies have to be assumed as a hypothesis for later HW integration. This is a hint to the design to respect.
9. postponed to the next iteration by the design.
10. see 10.
11. The state: power off and power on (start-up position) is missing inside the model.
12. Not part of the implementation, see 10.
13. Assigned to @jakobgartner

[MarcBehrens]

answer to 6: According to D2.4 Chapter 7.4.2 floating point is ruled out within the OBU.

point 7 is a design decision documented inside the basic types library: Obu_BasicTypes: L_internal_Type

point 15 will be covered in the TrackAtlas