RBC_Template 0.1.0 build 5fb9afb
Workspace master specification — safety-related railway software around an ERTMS Radio Block Centre (RBC), CENELEC EN 50128 / SIL 4
Loading...
Searching...
No Matches
Movement Authority length: analysis of an inconsistency, 2026-09-21

Trigger: IL Grants A Movement Authority To Second Train expects 1920 m and the RBC grants 1980 m; the web UI's end of MA did not sit where the granted route ends. This note records what was measured. **

Method

  • The real ab_gp_proc_ma_remaining_length_m() (RBC_GP, ab_gp_proc_ma.c) was called for every route and each of its trigger balises, against the generated site tables.
  • The same routes were measured from the railML chainage (parse_site()): distance along the direction of travel from the balise to the end signal.
  • The picture of every route (start signal = km +0.000, trigger balise, points, MA end) is test/RBC_Test_Env/doc/site_layout.svg, generated by etc/scripts/support_scripts/generate_site_svg.py.

What the numbers say (metres, without the 100 m MA overlap)

Route authored length trigger balise balise before (+) / inside (-) the start signal GP result railML chainage, balise to end signal
R_W_S1_X1 430 BG1001 -50 380 380
R_W_S2_X2 430 BG1002 -50 430 380
R_W_S3_X3 430 BG1003 -50 430 380
R_E_X1_DN2 2020 BG1009 +80 2080 2080
R_E_X2_DN2 2020 BG1010 +80 2020 2080
R_E_X3_DN2 2020 BG1011 +80 2020 2080

Routes 7, 8, 14 and 15 have a trigger balise that lies on a different route (1.9 km before their start signal); the function returns the authored route length there, which is documented behaviour, and they are not compared here.

Findings

  1. Identical geometry, different result. R_W_S1_X1 gives 380 but R_W_S2_X2 and R_W_S3_X3 (same start, end and balise chainage) give 430. R_E_X1_DN2 gives 2080 but R_E_X2_DN2 and R_E_X3_DN2 (same start, end and balise chainage) give 2020. The result depends on how each route's segment chain and trigger-balise entry happen to be authored, not on the track.
  2. Three different rules in one function (distance_from_lrbg_to_route_end()):
    • trigger balise on the start signal's own segment: route length minus the balise offset, or the full route length when the balise is at or before the start signal (the gap to the start signal is ignored);
    • otherwise a walk over the route's segment chain (the gap is included, so 2080 for R_E_X1_DN2);
    • balise not found on the chain: the authored route length.
  3. The authored data disagree with the chainage. R_E_X1_DN2..X3 are 2020 m long in the railML but the start and end signals are 2000 m apart (chainage 4720 to 2720). Their own switch SW_E1 sits 80 m before the start signal, at the same place as the trigger balise. R_W_X1_UP1: balise BG1001 lies 380 m before the start signal.
  4. The tests encode a fourth rule. Get Balise Distance From Start Of Route (ILSimSupportFunctions.py) returns 0 for a balise on another segment, so the Robot expectation is length - 0 - overlap = 1920 for R_E_X1_DN2. The GP unit test (test_ab_gp_proc_ma.c) asserts 1980 for the same route and cross-checks it against chainage (4800 - 2720 - 100). The same route therefore has two different "correct" answers in the repository. For R_W_X1_UP1 both agree on 1920, which ignores the 380 m from BG1001 to the start signal.
  5. The UI inherited it. The web runner derived the end of MA as balise chainage + granted length, so any of the above moved the end of MA away from the end signal. The UI now draws the end of MA at the signal named in ma_target_signal and the train front at the nearest signal facing its direction of movement (this session's web runner change).

Decision needed

Subset-026 measures the MA distance from the LRBG. If that is the rule, the length is distance(LRBG -> end signal) - overlap, from chainage, for every route, whether or not the balise is before the start signal:

  • one function, one rule, driven by chainage that the site generator writes into the tables (segment splits then no longer matter);
  • R_W_X1_UP1 then grants 2300 m (380 + 2020 - 100), not 1920, and several Robot expectations change;
  • the authored lengthM (2020) and the chainage span (2000) of the R_E_X*_DN2 routes must be reconciled in the railML;
  • the Robot helper should compute its expectation from the same chainage rather than from segment positions.

If instead "MA counted from the route start" is the intended rule, then R_E_X1_DN2 should give 1920, the segment-chain branch should not add the gap, and the GP unit test is the one to change.

Either way the two Docker/Robot expectations and the GP unit test have to agree; today they do not.

Decision and implementation (2026-09-21)

Decided: the MA is measured from the LRBG (first option above), and the overlap is skipped for now (RTE_EXAMPLE_MA_OVERLAP_M = 0).

  • ab_siteGP.h: ab_site_signal_t.chainage_m, generated by generate_ab_site_gp.py from the netElement sapi:chainage/@startKm plus the signal position (generation fails if a signal has none).
  • ab_gp_proc_ma.c: distance_from_lrbg_to_route_end() is now the difference of the balise and end-signal chainage along the route direction. The trigger-balise shortcut, the segment-chain walk and the authored-length fall-back are gone. ab_gp_proc_ma_extend() sets the MA to distance(LRBG -> the new end signal) - overlap and never shortens it, instead of adding the added route's authored length.
  • Values with the current site data: R_E_X1_DN2 from BG1009 2080 m, R_W_X1_UP1 from BG1001 2380 m (was 1920), R_W_S1_X1 380 m, R_UP1_UP2 from BG1005 3880 m (was 2000). Routes with identical geometry now agree.
  • Robot: Get Balise Distance From Start Of Route returns route_length - distance(balise -> end signal) from the same railML chainage, so the tests' length - offset - overlap equals the RBC's value; the generated MA_OVERLAP_M is 0.
  • GP unit test test_ab_gp_proc_ma.c asserts the values above.

Also on the chainage rule now (RBC_GA ab_ga_il.c): connecting a route sets the granted length to distance(LRBG -> that route's end signal) - overlap (never below what the train holds) instead of adding the route's own amount, which would double count once the LRBG rule applies; releasing a route re-derives the length from the last route the train still holds instead of subtracting the released route's authored length.

Not changed, for the railML author: finding 3 above is partly by design. The authored lengthM of 2020 m against 2000 m between the signals is the ~20 m of switch traversal the chainage does not carry (an accepted simplification noted in the earlier code), and the MA no longer uses it. SW_E1 and the trigger balises of R_E_X1..X3_DN2 sit 80 m before the routes' start signals; whether the signals or the switch are misplaced needs the layout's author.