New FBS-Features And Current Developements

FBS Yearly Update February 2025

Additional changes in context of railML-export reorganisation:

  • The developer mode ‘remembers’ the last export settings used and displays them (again) when it is called up again - if semantically possible (layers, circulation plans). On the other hand, this is not intended when predefined templates are called up repeatedly, so that old train filters are not still active without being recognised. If you explicitly want this, please create a user-defined template based on a predefined one.
  • The numbering of the section headings of the settings has been abandoned, as all sections are only visible in developer mode. The collapsibility of the areas is no longer important, but is still retained. They are all expanded by default.
  • As railML does not support layers for trains, the layer that contains the most trains is preset when a template is selected - if several layers contain trains. This means that Filter trains and train parts can be switched on instead of Export all trains and train parts, even though the former has not been explicitly selected.
  • The choice of which station are exported can be set more ‘sensitively’: If no lines and line tracks are exported, stations can be selected according to traffic stop, operating stop and direction of travel, so that in particular ‘backward’ block signals (those that are only valid for the opposite direction) are not output on the trains. If lines and line tracks are exported (which should be rare, as infrastructure data exchange is not an intended use case), this option is not available because there should be no contradiction between the sequence of stations on the exported infrastructure and on the trains. Exceptions exist for individual special export destinations.
  • The option Export trains with run times and supplements (<sectionTT>.<runTimes>) can also be selected if not all stations are exported - the run times and supplements are cumulated via skipped stations if necessary.
  • A large number of previously defined (always exported) attributes are now optional, e.g. linear time adds as percentage values, status, train types, product , line designations and kilometre zones with absolute positions. The background to this is usually to reduce semantic dependencies in the railML files (and therefore sources of error), such as route section breaks (<trainPart> breaks) only due to changing statuses.
  • The export of direct connections (in railML: commercial trains) now also enables the disintegration of primary/secondary paths, i.e. secondary paths create their own direct connections with disjoint traffic days. This means that usual primary key rules may not be adhered to (secondary path index=2 becomes primary path index=2, whereby this index occurs twice) and a 1: 1 relation between FBS train parts and railML-<trainPart>s no longer exists (an FBS train part in the primary path becomes two railML-<trainPart>s because there is still a secondary path somewhere that needs to be resolved), but the target programme no longer needs to know what secondary paths are - which will probably increase with TTT due to their abandonment.
  • The handling of routes with protected infrastructure in railML export has changed: Previously, the entire network could not be exported with routes and tracks if at least one protected route was included. As a result, no route numbers were available in exports of such networks. Now the topology (route numbers, tracks, owner, single/branch track, operating points including block signals and kilometre markings) is no longer considered worthy of protection and can be exported freely (including block signals in order to avoid complex dependencies if stops are made at protected block signals). The remaining infrastructure details (speeds, gradients, curves, tunnels, route classes) are only suppressed for the specifically protected routes, no longer across the entire network. It is no longer recognisable at the user interface whether something that cannot be exported is present in the network. An (ignorable) warning is therefore displayed during the export if infrastructure has been omitted during the export.
  • The previous warning The station ... is in the network several times with different properties. This is not possible in railML. The station can be exported as ... is now only displayed in developer mode (in the future also for predefined templates for the purpose of infrastructure data exchange, if such a presetting should ever exist).
  • The possible checks to be carried out during the export have been extended to meet the requirements of the presently known export targets. For predefined templates, the checks are used implicitly ‘in the background’; in developer mode, they are visible and freely usable for the sake of completeness. It is to be expected that the list will continue to be expanded in a more or less arbitrary manner (as it is only predetermined by export targets, which we can hardly influence).
  • The remarks of journeys/services in the circulation plan(which can also be used for labelling in the timetable graphic - option label with remark) are exported in railML under <blockPart>. des­cription (if not empty). This applies retroactively to all railML versions from 2.0 onwards