Radio Block Center

from Wikipedia, the free encyclopedia
The RBC in ETCS Level 2 (variant without light signals)

The Radio Block Center ( RBC , German ETCS route center ) is an essential component of the European Train Control System (ETCS) in levels  2 and 3 . His job is to guide and monitor the trains in his area. It receives the information required for this from the signal box and the train (via position reports ) and thus generates ETCS travel permits , which it sends to the train by radio (usually GSM-R ).

RBCs are offered by Alstom , Ansaldo , AZD Praha, Bombardier , Siemens (formerly Invensys ; "Trainguard") and Thales .

hardware

A radio block center

The RBCs of the various manufacturers are structured differently, but are based on the same basic concept. A "safe computer" carries out all safety-relevant functions. It is connected to other computers via a local network. These are used to operate the RBC, as a protocol converter and to store diagnostic information and legally relevant data (black box). This structure can be seen in the example of the RBC from Thales :

  • The RBC Core is the secure computer (2oo3 computer) for the functions of the RBC.
  • The Protocol Conversion Unit is a secure computer (2oo3 computer) for converting the interlocking protocol into the RBC-internal protocol.
  • The redundant IP - router , the interface of the RBC with the outside world.
  • The Operation and Maintenance Server (1oo2 computer) collects diagnostic data and distributes it to connected operator stations. It also backs up legally relevant data.
  • Redundant LAN switches for internal RBC communication.
  • The Radio Communication System Server is the interface to the GSM-R network.
  • The patch panel is the physical transfer interface to external systems.

Furthermore, several fans and a cabinet supervision module for monitoring the control cabinet are built into the RBC. The total power consumption is approx. 1000 watts.

Functions

Common RBC functions that are implemented similarly in many countries include:

  • Generation of driving permits
  • Recording of a train within an RBC area
  • Recording of a train entering an RBC area
  • Handover of a train to a neighboring RBC area
  • Exit of a train from the RBC area
  • Driving in different ETCS modes , e.g. Full Supervision (FS) , On Sight (OS) , Staff Responsible (SR) , Shunting (SH) or Reversing (RV)
  • Provision of concatenation information
  • Change between different ETCS modes.
  • Announcing a radio hole
  • Evaluation of potentially dangerous situations and commanding emergency stops
  • First assignment of a route to a train
  • Chasing the train
  • Acquisition of diagnostic information (e.g. references to missing balises from the trains)
  • Setting up temporary speed limits
  • Strengthen and weaken trains (joining and splitting)
  • Sending the national values to the train
  • Monitoring of the radio connection
  • Determination of the safety reactions in the event of certain incorrect situations on the train
  • Stop evaluation

In addition to the European ETCS specification, the functions controlled by an RBC are largely based on the requirements of the operator. The type of implementation is strongly influenced by the operational requirements. For example, the ETCS mode "Reversing" has so far only been implemented in Switzerland; the RBC software used in other countries does not use this function. In addition to the functions listed above, many other functions are used that enable the operation required in accordance with the operator's specifications.

Interfaces and standardization

Functions, user interfaces and system architecture of the ETCS centers are not standardized and are subject to a large number of national characteristics. For example, the operation of some railways has been fully integrated into the existing interlocking interfaces, while others use completely separate user interfaces and hide certain RBC information (e.g. position and speed of trains). The interfaces between interlockings and ETCS centers are also country-specific.

While both the radio interface to the train and the interface between two neighboring RBCs are determined by the ETCS specification, the interface to the interlocking and to the operator of the RBC can differ depending on the manufacturer and country.

  • RBC-OBU (on-board unit or vehicle)
    • Subset-26 Chapter 7 "System Requirements Specification ERTMS / ETCS language",
    • Subset-26 Chapter 8 "System Requirements Specification Messages",
    • Subset-37 "Euroradio"
  • RBC-RBC
    • Subset-039 "FIS for the RBC / RBC handover",
    • Subset-098 "RBC-RBC SAFE Communication Interface"
  • RBC signal box (national)
    • Germany: SAHARA / H3-SZS (H3 standard train protection interface) or RaSTA / SCI-RBC (Rail Safe Transport Application)
  • RBC operator (national)
    • Germany: SBS (standard user interface)

The RBC function itself is not specified in detail in Europe. Various concepts, operating modes and scenarios are defined (Subset-026), but no details as to when which ETCS mode should be used or how certain operating scenarios are implemented. Therefore, every route operator must define the operational processes under ETCS management and convert these operational processes into operational-technical requirements for the RBC. These are usually in the form of operational technical specifications, on the basis of which the manufacturers create their technical requirements specification that they implement technically. For this reason there is no uniform RBC function, but these differ from operator to operator and sometimes from route to route.

RBCs are usually connected to electronic interlockings . However, there is the possibility of connecting RBCs to any type of interlocking that provides the information required for MA generation. Essentially, these are the signal pattern and the position of the points. There are protocol converters for relay interlockings which pick up the information on the relay frame and convert it into telegrams that the RBC can understand. No protocol converters are currently known for mechanical and electromechanical interlockings, but they are theoretically possible. Since these interlocking designs also have block devices that do not provide the signal information at a central point, the effort involved in providing these signal images of the block is considerable. Therefore, in the case of mechanical and electromechanical interlockings, when the route is upgraded with ETCS, ETCS Level 1 will probably be set up, as this is the technically simpler and cheaper way.

The operation of the RBC essentially comprises two parts. On the one hand the maintenance access and on the other hand the operation of the RBC by the dispatcher (Fdl). The maintenance access enables the retrieval and saving of fault reports and log files, the uploading and updating of software and configurations and the restart of the RBC. The operation by the dispatcher essentially serves to enter, query or activate temporary data on the RBC. This includes speed restrictions (also train category-related), temporary ETCS exits, emergency stops and text messages to the driver. The user interfaces also allow trains to be tracked. The update rates are higher than with the interlocking user interface, which only receives its information via the track occupancy reports. The operating concepts for the RBC vary greatly depending on the country. In some countries the dispatcher is not allowed to operate the RBC, in most countries the function is restricted (e.g. a dispatcher is not allowed to restart the RBC). In many countries a certain dispatcher is responsible for an RBC, but there is also the possibility that several dispatchers operate an RBC and each is responsible for his area. There are areas of overlap at the boundaries of the administrative districts, which must be processed in cooperation between the Fdl.

Planning and project planning

In addition to the basic operational and technical specifications of the individual operators and the interfaces to be provided, an individual image of the infrastructure in its area is created for each RBC. These include signal, switch, balise locations, speeds and height profiles (gradients), but also special infrastructure areas (track conditions, e.g. overflow limits, platforms or known dead spots).

The operator transfers this information to the manufacturer as plan part 1 in the form of plans and tables. Building on this, the RBC manufacturer creates a project plan tailored to the respective infrastructure and manufacturer-specific features (plan part 2). This RBC-specific configuration is installed on the RBC together with the generic application software. The format and the data structures of a configuration are not standardized in Europe and therefore differ depending on the manufacturer.

In addition, short-term infrastructure restrictions such as speed restrictions, construction work, temporary ETCS exits, dead spots, notifications to the engine driver can be stored. As with the fixed project planning, it must be ensured that when the RBC is restarted, these restrictions remain active until the defined end of their validity or active cancellation by the operator.

Testing

ETCS Level 2 / 3 systems are highly complex systems whose correct operation can only be detected by appropriate analysis and testing. The standards EN 50128 for software and EN 50129 for hardware and systems form the basis for this. The RBC are developed and tested according to these standards. In addition, the test cases defined in subset-76 must have been executed successfully for the EC certificate of conformity of an RBC. However, the subset-076 is heavily loaded with vehicles, so that the trackside function is not fully tested even when the subset-76 is executed. The manufacturers of the RBC try to compensate for this with their own test cases. This leads to different interpretations of the ETCS specification, so that each manufacturer implements slightly different test cases and accordingly the RBC show different system behavior. If such a different behavior becomes known, this issue is clarified within UNISIG and the specification is adapted or specified more precisely via a CR (Change Request).

After the components have a certificate / declaration of conformity, they can be placed on the market within the EU. As a rule, first prototypes (initial applications) are built and integration tests are carried out in order to integrate an RBC into the route. Here, the RBC is first set up on site and connected to the energy supply or uninterruptible power supply. At the same time, the balises will be installed on the route. The next step is integration with the signal box. The telegram transmission and the correct configuration of the transmitted elements between STW and RBC (signal, switch, track occupancy, routes, etc.) are checked. The next step is the integration of the RBC into the GSM network. Then test keys for test vehicles are stored in the RBC, with which the first test drives can be carried out on the route. When using it for the first time, a system validation is carried out in cooperation with the operator. After the route has been successfully approved or after a successful system validation has been used for the first time, the keys for the ETCS vehicles are stored and the route is released for ETCS operation. For this purpose, an EC declaration of verification is issued by a notified body and a commissioning authorization is issued by the national approval authority.

safety

RBCs must guarantee a very high level of security. The safety goal to be observed for the route and speed monitoring of ETCS is specified in the TSI:

"For the hazard 'exceeding speed and / or distance limits advised to ETCS' the tolerable rate (THR) is 10 -9 h -1 for random failures, for on-board ETCS and for trackside ETCS." Exceeding the permissible speeds and lengths may not occur more frequently than once per billion hours in ETCS on the track and vehicle side.)

This target value is broken down further in subset 91: "The hazard rate for the ETCS trackside system, less those parts forming part of the transmission system, shall be shown not to exceed THR Trackside = 0.67 * 10 -9 dangerous failures / hour" ( Dangerous errors in the trackside ETCS system, regardless of the transmission system, must not occur more than once every 1.5 billion hours.)

The following safety goal applies to the radio transmission of the travel commands to the train: "Corruption of radio message: The requirement for the non-trusted part of TR-EUR-H4 is that the non-trusted ETCS trackside radio transmission equipment shall respect the definition of non-trusted given in paragraph 5.1.1.6 and the THR of 1.0 * 10 −11 Dangerous failures per hour "(Dangerous failures in the transmission system must not occur more than once every 100 billion hours.)

The security goals apply to the reference infrastructure and operating parameters assumed in subset 91. If this is deviated from, the security goals must be adapted accordingly. With these specifications, the safety target for an RBC is above the SIL 4 level of EN 50129.

Example of operational processes in an RBC

A train is approaching the boundary of an ETCS area. He drives through a "session balise group". From the balise group he receives the telephone number of the RBC, the ID of the RBC and the ID of the balise crossed. The train establishes a connection to the RBC and logs on with its OBU_ID. The RBC receives the train data from the vehicle and its position in reference to the last crossed balise group ( position report , ETCS odometry ). The vehicle receives the "National Values" (via Balise and / or by radio). The vehicle regularly reports its position to the RBC. When the vehicle approaches the border to the RBC area, the RBC sends the vehicle the track description and a movement authority. The RBC announces the level transition to the train at the border. At the boundary then the train changes to ETCS Level 2 / 3 . (This can also be initiated by a level transit balise group.) When the train enters, it switches the driver's cab display to ETCS and the driver receives his command values ​​from the driver's cab signal. Whenever the train approaches the end of its movement authority, it sends an MA request to the RBC at a time interval before the brake is applied . The RBC uses route information or points and signal information received from the signal box to determine the route in front of the train. If this route is clear and secure, it transmits the track description and a movement authority to the train. If the route is completely secured, a movement authority is issued for the full supervision mode (FS). If the signal box or the RBC does not have complete or valid information about the vacancy of the route section to be traveled, the RBC can issue an On Sight-MA (OS-MA, German drive command to drive on sight). If the RBC does not have any valid or current data on the train position, the RBC Staff Responsible (SR, German engine driver responsibility) can give orders. This continues until the end of the RBC range is reached. There the train receives a level transition order from the RBC for the respective level after the RBC border. The movement authority still covers the area of ​​change or, alternatively, the RBC issues a movement authority with “Limit of Authority” (LoA), which releases the train at the end of the MA with a speed> 0.

Efficiency

The performance of an RBC essentially depends on its computing power and the data transfer rate of the networks. Today's RBC can manage around 10 interlocking interfaces and thus run 120 trains. The interlockings are usually connected to the RBC via an IP network. The available bandwidth is relatively high here, so that the limit is limited by the computing power of the RBC. The limit is defined by the fact that the RBC must react to changes in the interlocking elements (switch and signal) within a certain time ( real-time requirement ). On the other hand, the available computing power has increased in such a way that, in the sense of a control loop, the reporting times from the sensor on the route via the interlocking to the RBC also play a role.

The other limit is the data transmission of the network between the RBC and the train. The RBC is connected to the GSM-R network via S 2M interfaces. Each of these interfaces provides 30 independent transmission channels, each channel corresponding to a fixed connection of the radio network ( CSD ) to one vehicle. This is why the performance of the RBC is often specified in increments of 30. For reasons of availability, one more S 2M interface is usually used than would be necessary for the maximum number of trains, so that if a line fails, there is no impairment of train traffic. The ETCS on-board unit is usually connected to send / receive units (EDOR) for GSM-R.

In individual cases, packet-switched data transmission using GPRS is already being used in the radio network , which has been standardized with GSM-R Baseline 1 . This means that more trains can be run per GSM-R channel. With this extension, the RBC with IP network can also be coupled to the GSM-R network, which increases the performance and simplifies the network technology. In deviation from the ETCS specification, other carrier systems (e.g. TETRA , LTE ) are also possible.

The processing time of the RBC to generate a travel permit is in the order of 0.5 to 2.5 seconds.

Further developments

There are already functioning and operational ETCS systems. These show the performance of the system, but the possibilities that this system offers have not yet been fully exhausted. A targeted further development of the system can increase the performance even further. There are already some approaches for this. For example, the strict cancellation of the route protection function in the interlocking by the train protection function in the RBC. The RBC can provide flank protection if it can ensure that a train in a flank protection area does not have a movement authority. Another function is the faster resolution of routes with the help of the RBC. The slip part of an entry road can be resolved when the train has come to a standstill. So far, the slip path has been resolved with a time delay. In future, the RBC can report the standstill of the train to the signal box. These functions are already possible today with the European specifications. Further functions require the extension of the European specifications. Currently, ETCS is used purely as a safety system, which monitors the maximum permissible speed of the train. In the future, for example, there could also be specifications for an optimal speed so that trains no longer run into slower trains or have to wait at the entry signals in front of stations if the station tracks are still occupied. There are already first approaches, but text messages are sent to the driver, which is less efficient than the integration into an automatic driving and braking control .

The dispatcher can also be supported by ETCS in the future. Since the RBC regularly receives the train positions from the trains, these can be displayed very precisely, so a dispatcher can quickly recognize when a train comes to an unscheduled standstill or is traveling at too low a speed. This gives him the opportunity to react more quickly to deviations in operation.

Errors and operational abnormalities

  • On September 16, 2002, an RBC safety shutdown occurred due to an error in one of the two communication computers of an RBC on the ETCS test route Zofingen – Sempach . It took 128 minutes to rectify the fault and twelve trains were delayed. The cause was the interface between the RBC and the interlocking interface. Overall, the RBC proved to be stable in the first few weeks of operation on the pilot route; numerous ETCS disruptions largely had other causes.
  • On October 16, 2007, during the test phase of the Lötschberg base tunnel , an RBC in front of the tunnel "lost" the emergency stop order for a train during its level change from level 0 to level 2 and instead issued a travel permit. As a result, the train ultimately opened a switch with a moving centerpiece at the north portal of the tunnel. There was property damage of around half a million Swiss francs. A software error was identified as the cause, which led to the loss of an emergency stop order during the two to three second log-in process. The error was fixed in early 2008.
  • On January 25, 2016, a power failure in the Bodio rail technology building of the Gotthard Base Tunnel led to the failure of the four RBCs; backups failed during startup. The lost location data of the trains either had to be collected or the route had to be cleared at 30 km / h on sight.
  • After a routine restart of one on RBC on the Cambrian Line , the system stopped transmitting slow speed zones that had existed for a long time to the vehicles. The error was not visible to the dispatcher. As a result, a speed limit stop in front of a level crossing was not transmitted and the necessary approach time was not reached. As it turned out, the speed limits indicated to the dispatcher did not correspond to those stored in the RBC. There was no clearly defined mechanism for this, and the underlying software design documentation showed deficiencies.
  • On March 6, 2018, the RBC on the new Mattstetten – Rothrist line failed . Five trains on the route suffered delays of up to 110 minutes. The cause was found to be a slow drive when changing level at the beginning of the route, which led to an emergency shutdown. To compensate, an additional group of balises was installed in all five level transition areas.
  • During test drives as part of the ETCS introduction in Denmark on May 16, 2018, two trains approached each other between Kvissel and Sindal and came to a standstill in 177 m due to braking by the train drivers involved. The infrastructure operator Banedanmark described the incident as not relevant to safety - ETCS worked correctly and prevented a collision.
  • On September 18, 2018, there was a safety shutdown of the RBC of the Mattstetten-Rothrist NBS after a fire-fighting and rescue train drove back from an operation without an ETCS on-board device at the top and the position reported by the locomotive at the end of the train did not match the Message from the axle counter matched. As a result, there was a data inconsistency that led to a safety shutdown. After exchanging three security cards, the RBC was restarted after 2 hours and 13 minutes. An order was issued to stop such operations.
  • In the interplay of vehicle odometry and RBC, two trains in Switzerland were mistakenly issued a travel permit that was not valid for them in 2019 .
  • On June 18, 2019, there was a safety shutdown of the RBC Innsbruck after several freight wagons had derailed in Kirchberg in Tyrol and a. had slashed a fiber optic cable. After the RBC Innsbruck had also taken over its function due to maintenance work on the RBC Vienna, ETCS operations in the Vienna area were also temporarily disrupted. While the RBC Vienna started up again immediately and was able to start operations, the RBC Innsbruck was only started up again gradually after three and a half hours.

Others

The term RBC is also used in the area of Communication-Based Train Control (CBTC), which is more widespread in Europe in local transport systems .

literature

  • Michael Dieter Kunze: Subsystem on the infrastructure side . In: Jochen Trinckauf , Ulrich Maschek, Richard Kahl, Claudia Krahl (eds.): ETCS in Germany . 1st edition. Eurailpress, Hamburg 2020, ISBN 978-3-96245-219-3 , pp. 77-82 .

Individual evidence

  1. ↑ Signaling supplier reopens branch . In: Railway Gazette International . tape 176 , no. 2 , 2020, ISSN  0373-5346 , p. 11 .
  2. ↑ Steffen Wolter, Jörg Demnitz: RBC simulations in an international comparison. (ZIP with several PDF files; 18.2 MB) (No longer available online.) Scheidt & Bachmann, September 25, 2015, p. 10 , archived from the original on March 7, 2016 ; accessed on March 7, 2016 (file "08 Steffen Wolter and Jörg Demnitz.pdf"). Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.  @1@ 2Template: Webachiv / IABot / tu-dresden.de
  3. ↑ Study on the introduction of ETCS in the core network of the Stuttgart S-Bahn. (PDF) Final report. WSP Infrastructure Engineering, NEXTRAIL, quattron management consulting, VIA Consulting & Development GmbH, Railistics, January 30, 2019, p. 267 , accessed on April 22, 2019 .
  4. ↑ First stage Bahn 2000 endangered? In: Swiss Railway Review . No. November 11 , 2002, ISSN  1022-7113 , p. 499 .
  5. ↑ Driver's cab signaling Zofingen - Sempach in operation . In: Eisenbahn-Revue International . No. 6 , June 2002, ISSN  1421-2811 , pp. 276 f .
  6. ^ ETCS accident on the Lötschberg baseline . In: Eisenbahn-Revue International . No. December 12 , 2007, ISSN  1421-2811 , pp. 584 f .
  7. ↑ Second ETCS software error put the Lötschberg base tunnel at risk . In: Eisenbahn-Revue International . No. 1 , January 2008, ISSN  1421-2811 , p. 22 f .
  8. ↑ Total failure on the Gotthard axis . In: Eisenbahn-Revue International . No. 3 , March 2016, ISSN  1421-2811 , p. 131 .
  9. ^ Cambrian ETCS Failure to be investigated . In: Modern Railways . tape 77 , no. 4 , April 2018, ISSN  0026-8356 , p. 15 .
  10. ↑ Report 17/2019: Loss of safety critical signaling data on the Cambrian Coast line. Rail Accident Investigation Branch, December 19, 2019, accessed October 12, 2020 .
  11. ↑ Puzzling RBC failure on the Bahn-2000 route . In: Swiss Railway Review . No. 4 , April 2018, ISSN  1022-7113 , p. 170 .
  12. ^ Incident during ETCS test drives in Denmark . In: Eisenbahn-Revue International . No. 10 , October 2018, ISSN  1421-2811 , p. 532 .
  13. ↑ RBC shutdown due to LRZ . In: Swiss Railway Review . No. December 12 , 2018, ISSN  1022-7113 , p. 614 .
  14. ^ The massive consequences of the derailment in Kirchberg in Tirol . In: Railway Austria . No. 9 , September 2019, p. 488 .
  15. ^ Radio Block Center. In: bombardier.com. Bombardier Transportation, 2017, accessed April 6, 2017 .