EP4124540A1 - Method and device for operating a driving lock for a track-bound vehicle - Google Patents

Abstract

The invention relates to a method for operating a driving lock (FS) on a route for a track-bound vehicle (FZ), in which a braking process is triggered in the track-bound vehicle (FZ) when it passes the activated driving lock (FS) on the route . The driving block (FS) is implemented by a trackside device (RSU) that is placed outside of a track (GL) forming the route, the location of the driving block (FS) on the route being virtually specified and made available by location information. A status signal indicative of the drive interlock (FS) activation status is generated and provided. The invention also includes a driving lock (FS), a vehicle (FZ), a computer program product and a provision device.

Description

The invention relates to a method for operating a driving lock on a route for a track-bound vehicle, in which a braking process is triggered in the track-bound vehicle when it passes the activated driving lock on the route. The invention also relates to a driving lock with a trackside device. Furthermore, the invention relates to a vehicle with a transmitting and receiving device. Finally, the invention relates to a computer program product and a provision device for this computer program product, the computer program product being equipped with program instructions for carrying out this method.

A traffic block is usually a physical device for the safe (safety) monitoring of a point on a route that is not allowed to be passed (at least temporarily) by a lane-bound vehicle. The driving block is usually implemented by a route device in the track (inductive, magnetic or mechanical driving block, coupling coil, Eurobalise or similar) that sends the information of travel release (corresponds to inactive driving block) or stop (corresponds to activated driving block) to a corresponding antenna when passing by crossing the route setup sends. The vehicle device then initiates braking when "stop" is received.

The components mentioned require a certain amount of space. In particular in the case of so-called low-floor vehicles (e.g. trams), in which the space between the vehicle floor and the track is limited, space problems arise when installing the components mentioned. In addition, the components require a certain amount of maintenance to avoid malfunctions. In particular, components installed in the track of trams are not only tram, but also by other vehicles using the road. This causes increased mechanical stress on the components, which increases their susceptibility to failure.

In metro and mainline systems, continuous monitoring is often used to prevent danger points from being overrun, such as ETCS (European Train Control System), PTC (Positive Train Control) and CBTC (Communication-Based Train Control). Continuous monitoring eliminates the need to set up a travel lock, but the system of continuous monitoring is considerably more complex. It is therefore only worth replacing the travel locks if continuous monitoring of the operation of the lane-bound traffic is planned anyway for other reasons.

The document US2021206407A1 describes systems and processes for virtual journey stops in rail networks. The rail network includes one or more trackside control units configured for use on or near tracks in the rail network. Each wayside control unit is coupled or connected to a train signal. The train-based control unit is configured to communicate with each wayside controller.

The object of the invention is to provide a method for operating a driving lock on a route for a track-bound vehicle or a driving lock suitable for carrying out the method and a vehicle suitable for carrying out the method, which / with a low cost of components a high Reliability is guaranteed and can also be used in particular for low-floor vehicles. In addition, the object of the invention consists in specifying a computer program product and a provision device for this computer program product, with which the aforementioned method can be carried out.

This object is achieved with the subject matter of the claim (method) specified at the outset, according to the invention, in that the driving lock is provided by a trackside device is realized, which is placed outside of a track forming the route, the location of the driving block on the route being determined and made available virtually by location information and a the activation state of the driving block, ie a driving release (corresponds to inactive driving block) or stop ( corresponds to activated driving lock) indicating status signal is generated and made available.

The functionality is implemented digitally with virtual driving barriers instead of with physical devices on or in the track. As a virtual driving lock in the sense of the invention, a driving lock is understood whose place of use on the route, d. H. in the track, is not determined by the installation location of a hardware component (the trackside device is located outside the track), but virtually by specifying location information of the driving block, i. H. the place where the driving lock is to take effect when activated. Instead of the transmission between the device in/on the track and the special ground-level receiving antenna on the vehicle, a data communication system is used to transmit the information, which is also available for other functions anyway. In this way, the position or location of the traffic block is determined virtually without a hardware component in the track forming the route.

This solution eliminates the need for route equipment on the track and the corresponding vehicle antennas. This leads to significant savings and solves problems of mounting the vehicle antenna, especially in low-floor trams. Instead, a data transmission system installed in the vehicle is used to transmit data relating to the use of the driving lock. Because the vehicle's data communication system is used (e.g. via 802.11p, Car2X/Rai12X, WLAN or LTE/5G), the solution is also highly reliable.

The location information can be, for example, the geo-coordinates of the virtual driving barrier (two-dimensional or three-dimensional including height information). Since the Driving blockage is based on a linearly extending route, alternatively, one-dimensional location information can also be used, which is based on the course of the route (for example as a value specified on the basis of the route kilometers).

Data that can be transmitted between the wayside device and the on-board device of a vehicle approaching the traffic block supports the method to exploit a status signal for the traffic block to decide whether the vehicle is allowed to pass the location defined by the location information or not . For this purpose, a status signal can be transmitted from the trackside device to the on-board device.

The location information of the driving lock can be stored in the on-vehicle device. This has the advantage that it is always available. This variant is particularly suitable for local transport, where trains always run on the same routes. Alternatively, it is possible to transmit the location information about the location of the driving lock from the trackside device to the onboard device.

Furthermore, according to the invention, a status signal indicating the activation state of the driving lock is generated and made available. The activation state of the driving lock is thus virtually described by the status signal. The status signal can assume two activation states of the driving lock, namely "free" and "locked". In the activation state "free" the driving barrier may be passed. In the "locked" activation state, the vehicle must come to a standstill in front of the driving lock. If it still passes the driving lock, a braking process, in particular an emergency braking process, must be triggered.

• keine streckenseitigen Einrichtungen im Gleis notwendig sind,
• keine fahrzeugseitigen Antennen notwendig sind die Ortspunkte, Daten- und Statusinformationen von Einrichtungen im Gleis direkt empfangen.

The invention differs from existing systems in that it

• no trackside facilities in the track are necessary,
• The location points, data and status information of facilities are not necessary on-board antennas received directly in the track.

It offers an easy-to-implement, digital, space-saving driving blocking function, especially for tram systems without complex antennas and track installations. The digital or virtual driving lock can therefore preferably also be used in low-floor vehicles (e.g. trams).

In connection with the invention, “computer-aided” or “computer-implemented” can be understood to mean an implementation of the method in which at least one computer or processor executes at least one method step of the method.

The term "calculator" or "computer" covers any electronic device with data processing properties. Computers can be, for example, personal computers, servers, handheld computers, mobile phones and other communication devices that process computer-aided data, processors and other electronic devices for data processing, which can preferably also be combined to form a network.

In connection with the invention, a “processor” can be understood to mean, for example, a converter, a sensor for generating measurement signals, or an electronic circuit. A processor can in particular be a main processor (Central Processing Unit, CPU), a microprocessor, a microcontroller, or a digital signal processor, possibly in combination with a memory unit for storing program instructions, etc. A processor can also be understood to mean a virtualized processor or a soft CPU.

In the context of the invention, a “memory unit” can be understood to mean, for example, a computer-readable memory in the form of a random-access memory (RAM) or data memory (hard disk or data carrier).

As "interfaces" can hardware, for example wired or as a radio connection, and/or software, for example as an interaction between individual program modules or program parts of one or more computer programs.

"Program modules" are to be understood as meaning individual functional units which enable a program sequence of method steps according to the invention. These functional units can be implemented in a single computer program or in several computer programs that communicate with one another. The interfaces implemented here can be implemented in terms of software within a single processor or in terms of hardware if multiple processors are used.

According to the invention, it is provided that the trackside device repeatedly receives, with the aid of a computer, current position information of a vehicle approaching the driving block, repeatedly compares the position information with the location information and sends the status signal to the vehicle if the comparison shows that the position of the vehicle in relation to the direction of travel of the vehicle and based on the route is at or behind the location of the driving lock, and the vehicle receives and evaluates the status signal with the aid of a computer, triggers a braking process if the status signal indicates that the driving lock is activated.

According to one embodiment of the invention, it is provided that the trackside device repeatedly sends the status signal to a vehicle approaching the roadblock with computer support, and the vehicle repeatedly receives and evaluates the status signal with computer support, repeatedly receives or determines current position information about its own position, repeats the position information compared with the location information and triggers a braking process if the comparison shows that the position of the vehicle in relation to the direction of travel of the vehicle and in relation to the route is on or behind the location of the traffic block and if the status signal indicates that the traffic block is activated.

The position information can be determined by the vehicle itself or by an external device. The position information can be sent by the vehicle or the external device to the trackside device, which receives this position information.

The position information is represented by position data and the location information by location data. The position information indicates the position of the subject vehicle and the location information indicates the location of the wayside facility. The location data and the position data are exchanged between the individual functional units. In this case, a data format is selected which can be evaluated by the individual functional units, so that the respective position information and location information can be derived from the data.

The position information must, so to speak, match the location information (same data format, same reference system for the test). This is due to the need for the position information to be compared with the location information. The decision is derived from the comparison as to whether the position information in relation to the direction of travel of the vehicle and in relation to the route is on or behind the location information. The reference to the direction of travel enables the decision to be made as to what is behind and what is in front of the location information. Before the location information means that the vehicle has not passed the virtual driving barrier (corresponds to the location information) and after the location information means that the vehicle has already passed the virtual driving barrier.

A reference to the route enables the data to be evaluated, also taking measurement inaccuracies into account. It is assumed that the track-bound vehicle stays on the route. Position information that is next to the route due to measurement inaccuracies can therefore still be taken into account, with such position information being related to the route (e.g. by projecting the point defined by the position information onto the Route).

According to one alternative according to the invention, it is provided that the trackside device processes the current position information of an approaching vehicle. The processing is carried out by comparing it with the available location information of the driving block. If this comparison reveals that the position of the vehicle on the route is at or beyond the location of the traffic block, the status signal indicating the condition of the traffic block is transmitted to the vehicle.

The vehicle receives the status signal and evaluates it. If the status signal indicates that the driving lock is activated, the vehicle should not have passed the driving lock. A braking process is therefore triggered immediately. This can be taken over by the vehicle control.

According to the other alternative according to the invention, it is provided that the trackside device repeatedly transmits the status signal to vehicles approaching the traffic block. In this case, the status signal is repeatedly received and evaluated in the vehicle and the available location information of the driving lock is repeatedly compared with the available own position information.

As soon as this comparison shows that the position of the vehicle on the route is at or behind the location of the driving lock and an evaluation of the status signal shows that the driving lock has been activated, a braking process is immediately triggered by a vehicle controller, for example.

The last-mentioned alternative of the invention has the advantage that a status signal must always be received by the vehicle. This means that the absence of the status signal indicates a fault in the driving lock and can therefore be evaluated as a safety-related incident. This case can be evaluated by the vehicle to increase safety (safety) and trigger a safety measure, for example braking if the virtual vehicle is driven over Driving lock There is no information about the status of the driving lock.

According to one embodiment of the invention, it is provided that the position information is generated by a locating device in the vehicle.

The position information can be generated, for example, by a navigation system GNSS (Global Navigation Satellite System) such as GPS (Global Positioning System) or by an odometry unit. If the position information is generated in the vehicle, this has the advantage that it is always available when a radio link is established between the vehicle and the trackside device. The vehicle can then make the available position information available via the radio link and update it at any time.

An alternative to this is location by a location device outside the vehicle. This then has to establish a data connection to the trackside device or the vehicle (depending on where the position information is to be processed) in order to obtain the location information regarding the train approaching the block transfer.

According to one embodiment of the invention, it is provided that the trackside device is connected to a safety device for vehicle traffic, with an operating state of the safety device being transmitted to the trackside device and the status signal being set depending on the operating state of the safety device.

The connection between the trackside device and a safety device has the advantage that the status signal for the driving lock, ie the activation state "free" or "blocked" can be determined depending on the operating state of the safety device. Safety devices for vehicle traffic are devices that regulate or secure vehicle traffic. As Examples are level crossings, signals, in particular light signals, and the like.

For example, if a level crossing has not yet closed or if a light signal is set to stop, the status signal must be set to "blocked". This means that the vehicle is automatically braked when the driving lock is passed. However, if the level crossing is closed or the light signal indicates passage, the status signal is set to "free" so that the vehicle can pass through the blockage.

According to one embodiment of the invention, it is provided that the safety device is designed as a signal.

The stated object is alternatively achieved according to the invention with the subject matter of the claim specified at the outset (travel lock) in that the trackside device can be placed outside of a track forming the route, with the trackside device being set up to carry out a method according to one of the preceding claims.

The stated object is alternatively achieved according to the invention with the initially specified subject of the claim (vehicle) in that the vehicle is set up to carry out a method according to one of Claims 1 to 6.

The advantages that have already been explained in connection with the method described in more detail above can be achieved with the device (ie the driving lock or the vehicle). What has been said about the method according to the invention also applies correspondingly to the device according to the invention.

Furthermore, a computer program product with program instructions for carrying out the method according to the invention and/or its exemplary embodiments is claimed, with the method according to the invention and/or its exemplary embodiments being able to be carried out in each case by means of the computer program product.

In addition, a provision device for storing and/or providing the computer program product is claimed. The provision device is, for example, a storage unit that stores and/or provides the computer program product. Alternatively and/or additionally, the provision device is, for example, a network service, a computer system, a server system, in particular a distributed, for example cloud-based computer system and/or virtual computer system, which stores and/or provides the computer program product preferably in the form of a data stream.

The provision takes place in the form of a program data block as a file, in particular as a download file, or as a data stream, in particular as a download data stream, of the computer program product. However, this provision can also be made, for example, as a partial download consisting of several parts. Such a computer program product is read into a system, for example using the provision device, so that the method according to the invention is executed on a computer.

Further details of the invention are described below with reference to the drawing. Identical or corresponding drawing elements are each provided with the same reference symbols and are only explained several times insofar as there are differences between the individual figures.

The exemplary embodiments explained below are preferred embodiments of the invention. In the exemplary embodiments, the described components of the embodiments each represent individual features of the invention to be considered independently of one another, which also develop the invention independently of one another and are therefore also to be regarded as part of the invention individually or in a combination other than the one shown. Furthermore, the components described can also be combined with the features of the invention described above.

• Figur 1 ein Ausführungsbeispiel der erfindungsbemäßen Vorrichtung mit ihren Wirkzusammenhängen schematisch,
• Figur 2 ein Ausführungsbeispiel einer Computer-Infrastruktur der Vorrichtung gemäß Figur 1 als Blockschaltbild, wobei die einzelnen Funktionseinheiten Programmmodule enthalten, die jeweils in einem oder mehreren Prozessoren ablaufen können und die Schnittstellen demgemäß softwaretechnisch oder hardwaretechnisch ausgeführt sein können,
• Figur 3 und 4 alternative Ausführungsbeispiele des erfindungsgemäßen Verfahrens als Flussdiagramme, wobei die einzelnen Verfahrensschritte einzeln oder in Gruppen durch Programmmodule verwirklicht sein können und wobei die Funktionseinheiten und Schnittstellen gemäß Figur 2 beispielhaft angedeutet sind.

Show it:

• figure 1 an exemplary embodiment of the device according to the invention with its functional relationships schematically,
• figure 2 an embodiment of a computer infrastructure of the device according to figure 1 as a block diagram, with the individual functional units containing program modules that can each run in one or more processors and the interfaces can accordingly be designed in terms of software or hardware,
• figure 3 and 4 alternative exemplary embodiments of the method according to the invention as flow charts, in which case the individual method steps can be implemented individually or in groups by program modules and in which the functional units and interfaces according to FIG figure 2 are indicated as examples.

In figure 1 a vehicle FZ is shown which is moving in a direction of travel FR on a track GL. The vehicle FZ is in a proximity zone NZ in front of a signal SG. Behind the signal SG, a siding NGL branches off from the track GL. This is a security zone SZ, which is located behind the signal SG and is to be protected by the signal SG from entry of the vehicle FZ when it indicates "stop". Since the signal SG can be run over by the vehicle FZ (for example, if the train driver is not paying attention), a driving lock FS is provided in addition to the signal SG, which, however, is designed as a virtual driving lock. This means that the driving block FS does not have any hardware elements that are installed in the track GL, but that it is defined by location information OI, which indicates the location of the driving block.

The virtual driving lock FS is made available by a trackside device RSU, in which a computer program runs which, among other things, allows the location information OI to be retrieved. The trackside facility RSU is connected to the signal SG via a seventh interface S7, so that the operating status of the signal SG can also be called up in the trackside equipment. In addition, the trackside device RSU has an antenna AT, just like the vehicle FZ, so that the trackside device RSU can communicate with the vehicle FZ by radio via a first interface S1. In addition, the vehicle FZ can call up navigation signals from a satellite STL via a second interface S2.

In this way, the vehicle FZ can determine its position and generate position information PI. For this purpose, the vehicle FZ is equipped with an on-board device OBU, which u. is connected via an eighth interface S8 to a first transmitting and receiving device SE1.

As the vehicle FZ approaches the signal SG in the direction of travel FR, the generated position information PI changes in the direction of the location information OI, which is assigned to the signal SG and the virtual driving block FS. If the signal SG is set to "stop", the vehicle FZ will usually come to a standstill before the signal SG. Should it nevertheless continue to drive, a corresponding message is generated by the trackside device RSU and a braking process is triggered in the vehicle FZ (more on this below).

In figure 2 the trackside device RSU and the onboard device OBU are shown as a block diagram. The on-board device OBU has a first computer CP1, which is connected to a first storage device SP1 via a fifth interface S5. This allows data to be retrieved and stored. Likewise, for retrieving and storing data, a second computer CP2 of the trackside device RSU is connected to a second storage device SP2 via a sixth interface S6. The second computer CP2 is also connected via a ninth interface S9 to a second transmitting and receiving device SE2, which is connected via the first interface S1 to the first transmitting and receiving device SE1 (as in figure 1 already described) is connected. The first Transmitting and receiving device SE1 is in turn connected to the first computer CP1 via the eighth interface S8.

In addition, the vehicle-side device has a locating device GPS, which figure 1 shown second interface S2 can form. The locating device GPS is connected to the first computer CP1 via a third interface S3. If locating via a GNSS is not possible, an odometry unit ODO, which can also perform a locating function, is connected to the first computer CP1 via a fourth interface S4.

There are two advantageous characteristics for the course of the procedure, which are Figures 3 and 4 are described.

In figure 3 the on-board device OBU takes on the task of checking whether the vehicle has driven over the driving block. In the method according to figure 4 the test is carried out in the trackside unit RSU. However, the method steps are analogous and in this respect are denoted by the same reference symbols.

In the method according to figure 3 the trackside device RSU starts first. First, in an input step for the operating state BZ_IN, an operating state of a route facility such as e.g. B. according to the signal SG figure 1 read in. Depending on this operating state, in a determination step for the status signal ST_STA, a decision is made as to whether the travel lock is "locked" or "free". These steps are analogous to the method according to FIG figure 4 carried out.

Now drives a vehicle into the proximity zone NZ according to figure 1 on, the process is started in the on-board device OBU. Position information PI is generated in a locating step for the vehicle position LOC_PI. This step is also part of the methods according to figure 3 and 4 analogous.

According to figure 3 is then the status signal STA for the driving block via the interface S1 from the trackside Device RSU handed over to the on-board device OBU (output step STA_OT and input step STA_IN). The same is done with the location information known in the trackside device RSU regarding the location of the driving blockage (output step OI_OT and input step OI_IN). In the on-board device OBU, an interrogation step LCK? takes place as to whether the status signal STA indicates that the driving lock is set to "locked". If this is not the case, a query step PI<OI? for the approach of the vehicle FZ to the driving lock FS. If there is still a distance to cover, the method is repeated in the on-board device with a new locating step for the vehicle LOC_PI. If there is no remaining distance to the travel lock FS, the process is stopped.

In the event that the query step for an active driving lock LCK? shows that this is set to "locked", is also used in a subsequent query step for the approach PI<OI? checked whether there is still a remaining distance to the driving lock FS. If this is the case, the method is repeated with the locating step for the vehicle LOC_PI. If this is not the case, a braking step BRC takes place immediately, in particular a step for emergency braking of the vehicle. The process is then stopped.

After the location information has been output by the trackside device RSU, a query step STP? after the end of operations. If this is reached, the process is stopped. If this has not yet been reached, the input step for the operating state BZ_IN is repeated.

So that in accordance with the method figure 4 the check with the query step LCK?, whether the driving lock is on "blocked", and the subsequent investigations that the vehicle has already reached the driving lock, can be carried out in the trackside device RSU, according to figure 4 transfer the position information PI generated in the on-board device OBU to the track-side device RSU via the interface S1 (output step PI_OT and input step PI_IN). Conversely, as in figure 3 described, a handover of Location information OI via the first interface S1 from the trackside device RSU to the onboard device OBU (output step OI_OT, input step OI_IN). This is used in the on-board device to execute a query step PI<OI? carry out whether the vehicle FZ has not yet reached the driving lock FS. If this is the case, the method is repeated with a further locating step for the vehicle LOC_PI. If this is not the case, the method is stopped in the on-board device OBU. The query step PI<OI is not absolutely necessary for the function of the procedure. In principle, it is sufficient that the on-board device OBU always sends its position and receives the status information STA of the driving lock. where the trackside RSU only sends the status if it is still relevant (ie PI<OI is true) for the vehicle (this variant is not shown).

After the position information PI has been entered, the trackside device RSU is asked whether the driving lock FS is “locked”. If this is not the case, then in a query step after the end of operation STP? asked whether the end of operation has been reached. If this is not the case, the procedure is repeated with the input step for the operating state BZ_IN. If this is the case, the process is stopped.

Should the query for the status signal STA in the query LCK? result in the driving lock FS being "locked", in a next query step PI<OI? checked whether the vehicle still has a remaining distance to the driving lock. If this is the case, is the already described step of querying after the end of operation STP? carried out. If this is not the case, an emergency signal EM is output (output step EM_OT) via the first interface S1 to the on-board device OBU (input step EM_IN). There, after the emergency signal EM has been input, a braking step BRC, in particular for emergency braking of the vehicle, is carried out and the method is stopped.

Reference List

car

vehicle

FR

driving direction

GL

Track

NGL

siding

AT

antenna

SG

signal

FS

driving lock

STL

satellite

OBU

on-board facility

RSU

trackside facility

NZ

proximity zone

SZ

security zone

CP1...CP2

computer

SP1 ... SP2

storage device

S1...S9

interface

SE1 ... SE2

Sending and receiving device

GPS

tracking device

ODO

odometry unit

BZ_IN

Input step for operating status

ST_STA

determination step for status signal

STA

status signal

STA _IN

Input step for status signal

STA _OT

Output step for status signal

LOC_PI

Locating step for vehicle

PI_IN

Input step for position information

PI_OT

Position information output step

OI_IN

Input step for location information

OI_OT

Location information output step

PI

position information

OI

location information

LCK?

Query step for active travel lock

PI<OI?

Query step for approximation

EM_IN

Entry step for emergency

EM_OT

Output step for emergency

EM

emergency signal

BRC

braking step

STP?

Query step for end of operation

Claims (9)

Method for operating a driving lock (FS) on a route for a track-bound vehicle (FZ), in which a braking process is triggered in the track-bound vehicle (FZ) when it passes the activated driving lock (FS) on the route, wherein the driving lock (FS) is realized by a trackside device (RSU) which is placed outside a track (GL) forming the track, wherein • the location of the driving blockage (FS) on the route is determined and made available virtually by location information (OI) and • a status signal (STA) indicating the activation state of the driving lock (FS) is generated and made available. characterized, that the trackside facility (RSU) is computerized • repeatedly receives current position information (PI) of a vehicle (FZ) approaching the driving block (FS), • repeatedly compares the position information (PI) with the location information (OI) and • sends the status signal (STA) to the vehicle (FZ) when the comparison shows that the position of the vehicle (FZ) in relation to the direction of travel (FR) of the vehicle (FZ) and in relation to the route on or behind the location of the Driving lock (FS) is, and and the vehicle (FZ) computer-aided • receives and evaluates the status signal (STA), • triggers a braking process when the status signal (STA) indicates that the drive lock (FS) is activated. Method according to claim 1, characterized, that the trackside facility (RSU) is computerized • repeatedly sends the status signal (STA) to a vehicle (FZ) approaching the driving block (FS), and the vehicle (FZ) computer-aided • repeatedly receives and evaluates the status signal (STA), • repeatedly receives or determines current position information (PI) of its own position, • repeatedly compares the position information (PI) with the location information (OI). • triggers a braking process when the comparison shows that the position of the vehicle (FZ) in relation to the direction of travel (FR) of the vehicle (FZ) and in relation to the route is on or behind the roadblock (FS) location and when the status signal ( STA) indicates that the drive lock (FS) is activated. Method according to one of the preceding claims,
characterized,
that the position information (PI) is generated by a locating device (GPS) in the vehicle (FZ). Method according to one of the preceding claims,
characterized,
that the trackside facility (RSU) is connected to a safety device for vehicular traffic, wherein • an operating status (BZ) of the protection device is transmitted to the trackside device (RSU) and • the status signal (STA) is set depending on the operating status (BZ) of the security device. Method according to claim 4,
characterized,
that the safety device is designed as a signal (SG). Driving lock (FS) with a trackside device (RSU), characterized in that
that the trackside facility (RSU) can be placed outside a track (GL) forming the route, the trackside facility (RSU) being set up to carry out a method according to one of the preceding claims. Vehicle (FZ) with a transmitting and receiving device (SE1), characterized in that
that the vehicle (FZ) is set up to carry out a method according to one of Claims 1 to 5. Computer program product with program instructions for carrying out the method according to one of Claims 1 - 5. Provision device for the computer program product according to the last preceding claim, wherein the provision device stores and/or provides the computer program product.

Images