An operating station can be provided with various abbreviations ("registers") in railML. This is done (from railML 2.2 upwards) in the attributes register and entry of the < designator > element of a railML operation station (< ocp >):

      <ocp id='ocp_DN'>
        <designator register='RL100' entry='DN'/>
        <designator register='IBNR' entry='8010089'/>
      </ocp>

Typical registers are RL100 (for German domestic stations), IBNR (International Station Number), PLC (Primary Location Code for TAF / TAP TSI), or CRD (Common Reference Database, ERA) 1.

Each of these registers has a different definition of "operating station" in detail - in some registers, operating stations are defined "more filigree", in others "coarser". In conclusion a 1: 1 assignment is not possible. In the same way, the FBS-internal concept of "operating station" cannot always be assigned to one of the registers 1 - 1, even if there is a certain flexibility on the FBS side, so that even register entries can be duplicated if only one register is used.

For example, Berlin Main station - Lehrter Bahnhof is assigned IBNR 8098160, whereas DB Netz AG divides it into the three BL, BLS and BHBF stations, as it is actually three independent track groups. Thus, if the three BL, BLS, and BHBF operating stations are distinguished in a railML file, all three must reference the same IBNR. If, on the other hand, only one operating station with the IBNR 8098160 were specified, this would have to list the three RL100 abbreviations.

This is, therefore, the fairly frequent division into "operational vs. traffic-related view". This does not have to be so; also within the operational or traffic point of view, different registers can come in detail to different results. For example, the bus stop assigned to a train station does not always have the same IBNR as the station.

The quasi-reversed case can also occur: For example,DB Netz AG often uses "parallel breakpoints", so breakpoints at different routes that fulfill the same traffic function (development). These would have to be strictly different operating stations - as breakpoints, they do not necessarily have an internal operational connection. Nevertheless, they are summarized under an operational code. Examples include Kürbitz (two breakpoints with the same name and the same RL100 abbreviation DKUR on two different routes) or Hervest Dorsten (RL100 abbreviation EHDT). Regensburg-Prüing's example shows that this is not always the case, and that this is where the "RL100" abbreviations NRPF and NRPH2 exist, depending on the route.

Of course, this topic also includes operating stations that are not included in a register. So there is about IBNR only for access points of travel, whereas company stations or pure goods traffic access points have no need to get along and consequently railML can not have such an indication. The repeated occurrence of "no abbreviation" also represents a primary key violation, which has to be taken into account when importing railML files and, if necessary, intercepted.

Conclusion: External key data in railML, such as the registers of the workstations, can inevitably not meet primary key data requirements. The reading software may have to process duplicates or missing data.

When exporting from FBS, there are also a number of optional testing possibilities that can detect and warn about the absence of abbreviations. This allows at least an "error early detection" and anger in the later import, for example, once an IBNR was forgotten.

¹ railML-version 2.30r611, www.railml.org, accessed on 01.05.2014
² track network Terms of Use of DB Netz AG, accessed on 25.05.2017