SYSTEMS AND METHODS FOR CONTROLLING A RAILROAD CROSSING GATE

Description

RELATED APPLICATION

This application claims priority to U.S. Provisional Patent Application Ser. No. 63/668,385, filed Jul. 8, 2024, entitled “System And Method For Controlling A Railroad Crossing Gate”, the disclosure of which is hereby incorporated by reference, in its entirety.

TECHNICAL FIELD

The invention relates generally to systems and methods for safely controlling a railroad crossing gate and, more specifically, to systems and methods for safely taking a highway crossing out of service for troubleshooting and maintenance.

BACKGROUND

Every year the operation of railroads in the United States results in a handful of tragic and costly accidents. A small percentage of these accidents are due in part to human error. Often times, these errors occur at locations utilizing highway-rail grade crossing warning systems (HRGCWS) to control the flow of motorist traffic across the rails. An HRGCWS refers to a safety system installed at a location where a roadway or highway intersects with the railroad. The intersection point is referred to as a grade crossing.

While an HRGCWS is designed to operate according to fail safe principles, standard maintenance periodically requires railroad employees to temporarily remove the HRGCWS from service using a bypass jumper. The presence of the bypass jumper removes traffic flow control from the HRGCWS by putting equipment into a permissive state. In this situation the signals and gates that protect motorists from oncoming trains are held up to allow traffic to continue to flow as normal. Unfortunately, in some situations, the bypass jumper is left in place when maintenance work is completed, resulting in equipment of the HRGCWS being left in a permissive state such that the equipment is unable to deter motorists from driving through the grade crossing.

To provide an example, the HRGCWS includes crossing equipment, such as crossing gates, which operate in a failsafe manner. Crossing equipment requires a voltage supply to be attached to its inputs to hold the crossing gates up and allow traffic to cross. The HRGCWS applies this voltage until it detects the presence of a train at which point the voltage is removed, causing the gates to lower. To conduct maintenance on the HRGCWS, the inputs must be disconnected from the crossing warning equipment, which removes the voltage, unless a bypass jumper is applied, and lowers the gates and prevents traffic from crossing.

Stopping the normal flow of traffic has obvious negative implications and is usually unacceptable. As such, the current practice involves wiring the warning equipment directly to a battery and providing the necessary voltage to keep the crossing gates up. Unfortunately, there have been times when the battery is not disconnected and the crossing gate is held up, even in the presence of a train, long after the maintenance was completed.

Current jumper policy requires wires with clips to be applied manually when making changes, repairs, or adjustments to signal equipment that bypass relay contacts or other controlling devices. A bypass jumper cannot be applied without permission from signal management and taking certain safety measures to ensure that maintenance is not performed at a time when a rail vehicle is passes the grade crossing.

When a bypass jumper is required, the maintenance worker must immediately notify the control station with information identifying the affected equipment, the location of the bypass jumper, the name of the maintenance worker applying the bypass jumper, authorization from a supervisor, date/time at which the maintenance is to be applied, as well as the anticipated duration. This information is documented in a jumper log.

Once the bypass jumper is removed and the system is restored to normal operation, the maintenance worker must again notify the control station to close out the jumper log entry. If the maintenance worker fails to remove the bypass jumper within the expected timeframe, a supervisor of the maintenance worker must be immediately notified. During multiple crossing outages, the Employee in Charge (EIC) documents in a field jumper application record log information such as the EIC name, date issued, tag numbers, names of employee using a bypass jumper, and crossing details.

Additionally, the maintenance worker must affix a lock tag on the door of the equipment case or signal bungalow, where the lock tag includes the date, tag number, and EIC name visibly displayed. Proper communication, documentation, and lockout/tagout procedures are critical when using a bypass jumper to ensure signal system integrity and safe train operations.

Also, while one or more of the problems described herein are described in reference to one bypass jumper, in many situations, multiple bypass jumpers need to be applied to perform railroad maintenance. For example, one bypass jumper may be applied per control circuit or input that needs to be overridden. That is to say, at crossings with multiple tracks, multiple gate mechanisms, or multiple control circuits, a bypass jumper is needed to bypass a specific relay or input line for each track circuit or warning device.

In more complex grade crossings, there may be many parallel tracks intersecting the roadway at a single location. At these crossings, an individual track may be divided into multiple track circuits or sub-segments that are each controlled and monitored separately by microprocessor-based equipment. For example, a given track could consist of four distinct track circuits that must all be taken out of service to ensure maintenance safety. However, in some cases, these multiple track circuits are collectively represented as a single line item on operational timetables. An operational timetable is a document or system used by railroad personnel to coordinate train movements and track assignments, often listing tracks by simplified identifiers (e.g., “Track 2”) without fully depicting their underlying control segments or circuit divisions. Additionally, railroads often label tracks in ways that do not correspond to intuitive geographic orientation. For example, a line running geographically north-south may be designated as east-west in railroad documentation, or what is labeled as “Track 1” may appear at the top of a schematic diagram while physically being located at the bottom of the crossing in the field. This inconsistency and complexity can make it difficult for maintenance workers to correctly identify and select the proper track segments to take out of service, increasing the risk of error, miscommunication, and unsafe maintenance operations.

In the railroad industry, the term “vitality” refers to the overarching principle of ensuring that all operations and equipment in a railroad system work harmoniously and without conflict. The term vitality often involves coordinating train movement permissions so that no two trains are ever authorized to occupy the same section of track at the same time, thereby avoiding conflicts that could lead to collisions. Vitality ensures the seamless operation of the railroad network by maintaining overall coordination and management of train movements to prevent accidents and maximize efficiency.

The term “functional safety,” on the other hand, is a specific discipline within the broader context of vitality. Functional safety involves implementing safety mechanisms within individual components and systems to prevent hazardous conditions resulting from equipment failures or malfunctions. Functional safety ensures that each piece of equipment, such as signaling systems, locomotives, and braking mechanisms, operates correctly and safely under all conditions, including potential fault scenarios.

Functional safety is a critical component in achieving vitality. Without functional safety, individual components and systems within the railroad could fail in ways that create hazardous situations, disrupting coordinated operations. By ensuring that each piece of equipment functions safely and reliably, functional safety supports the overall integrity of the system. This component-level risk management enables the railroad network to operate smoothly, consistently, and without conflict.

One way that the railroad industry has characterized function safety is through safety integrity levels (SILs). SILs have been defined by the International Electrotechnical Commission as “discrete levels for specifying the requirements for the safety functions to be allocated to the electrical, electronic, or programmable electronic (E/E/PE) safety-related systems.” A SIL indicates a degree of confidence that a safety function will be performed as intended. There are typically four SILs. The first SIL represents an integrity level needed to avoid less severe outcomes, i.e., relatively minor incidents, and can typically be achieved with fault-tolerance design following standard practice guidelines. The second SIL represents the integrity level needed to avoid more serious incidents, some of which may result in injury or death. The third SIL represents an integrity level required to prevent serious incidents that could involve a number of fatalities and/or serious injuries. The fourth SIL represents an integrity level necessary to avoid catastrophic events that could involve an even larger number of fatalities and/or serious injuries. However, when it comes to maintenance work performed on railroad equipment located at a grade crossing, conventional systems are often unable to provide a SIL needed to avoid more serious incidents.

For the reasons described above, what is needed is a system that improves the safety, reliability, and accountability while temporarily removing one or more components of an HRGCWS from service while performing maintenance tasks. Such a system should reduce the risk of human error associated with applying and removing bypass jumpers by enforcing proper authorization, communication, and documentation protocols. The system should also integrate an improved user interface to help maintenance workers clearly identify the correct track segments to take out of service, even in environments with inconsistent geographic labeling or complex schematic representations of railroad tracks.

SUMMARY

In an aspect of the invention, a system is provided for controlling one or more components of a gate system located at a railroad crossing. The system includes a jumper panel located in an equipment enclosure. The jumper panel includes one or more memories, a plurality of processors, and a selection interface configured to receive a selection of a segment of a track that corresponds to the one or more components of the gate system. The selection of the segment is indicative of a service request to disable operation of the one or more components of the gate system. The system further includes a computing device, communicatively coupled to the plurality of processors, the computing device comprising a memory and a processor. The system further includes a controller, communicatively coupled to the computing device, the controller configured to operate the one or more components of the gate system.

The plurality of processors of the jumper panel are to perform the following operations described below. For example, at least one processor, of the plurality of processors, to receive a track selection signal indicative of the service request to disable operation of the one or more components of the gate system. The at least one processor is further to receive, from the computing device, track status data indicating operational safety conditions for the selected segment of the track. Each of the plurality of processors are to determine whether the one or more components of the gate system satisfy predefined safety criteria based on the track status data. Each of the plurality of processors are further to determine whether to grant the service request based on whether the one or more components of the gate system satisfy the predefined safety criteria. In response to determining to grant the service request, the at least one processor is further to transmit the service request to the computing device. The computing device is to provide the service request to a dispatch server. The computing device is further to receive an approval message from the dispatch server indicating to disable the operation of the one or more components of the gate system. The computing device is further to provide, to the controller, instructions indicating to disable the operation of the one or more components of the gate system.

In an embodiment of the invention, the processor of the computing device is further to receive a message indicating that the operation of the at least one component of the one or more components of the gate system is to be re-enabled. The message is received based on expiration of a predefined timer indicating a maximum permissible duration for completing a maintenance task associated with the service request. In this embodiment, the processor of the computing device is further to provide, to the controller, instructions indicating to re-enable the operation of the one or more components of the gate system.

In another embodiment of the invention, the plurality of processors of the jumper panel include a first processor and a second processor. In this embodiment, when determining whether to grant the service request, the first processor is to determine to grant the service request and the second processor is to determine to grant the service request. In this embodiment, the first processor and the second processor are to compare a decision of the first processor to grant the service request and a decision of the second processor to grant the service request. In this embodiment, the first processor and the second processor are to grant the service request based on the first processor and the second processor independently determining to grant the service request.

In another embodiment of the invention, the plurality of processors of the jumper panel include a first processor and a second processor. In this embodiment, when determining whether to grant the service request, the first processor is to determine to grant the service request and the second processor is to determine to deny the service request. In this embodiment, the first processor and the second processor are to compare a decision of the first processor to grant the service request and a decision of the second processor to deny the service request. In this embodiment, the first processor and the second processor are to deny the service request based on the first processor and the second processor independently determining different grant-denial decisions. In this embodiment, at least one of the first processor and the second processor are to perform one or more actions to report and/or correct an error that caused the first processor and the second processor to determine different grant-denial decisions.

In another embodiment of the invention, the plurality of processors of the jumper panel include a first processor and a second processor. In this embodiment, when determining whether to grant the service request, the first processor is to determine to deny the service request and the second processor is to determine to deny the service request. In this embodiment, the first processor and the second processor are to compare a decision of the first processor to deny the service request and a decision of the second processor to deny the service request. In this embodiment, the first processor and the second processor are to deny the service request based on the first processor and the second processor independently determining different grant-denial decisions.

In another embodiment of the invention, the selection interface is a user interface that displays a selectable representation of the segment of the track in a manner that depicts a relative geographic location of the segment relative to geographic locations of other segments of other tracks which are also selectable via the user interface.

In another embodiment of the invention, each of the plurality of processors are to authenticate a maintenance worker submitting the service request. In this embodiment, each of the plurality of processors, when determining whether to grant the service request, are to determine whether to grant the service request based on whether the authentication is successful.

In another aspect of the invention, a method is provided for controlling one or more components of a gate system located at a railroad crossing. The method includes receiving, by at least one processor of a plurality of processors of a jumper panel located in an equipment enclosure, a track selection signal indicative of a service request to disable operation of the one or more components of the gate system. The method further includes receiving, by the at least one of processor, track status data indicating operational safety conditions for a segment of track corresponding to the one or more components of the gate system. The method further includes determining, by each of the plurality of processors, whether the one or more components of the gate system satisfy predefined safety criteria based on the track status data. The method further includes determining, by each of the plurality of processors, whether to grant the service request based on whether the one or more components of the gate system satisfy the predefined safety criteria. The method further includes providing, by the at least one processor, the service request to a dispatch server. The method further includes receiving, by the at least one processor, an approval message from the dispatch server. The approval message indicates to disable the operation of the one or more components of the gate system. The method further includes providing, by the at least one processor and to a controller configured to operate the one or more components of the gate system, instructions indicating to disable the operation of the one or more components of the gate system. The instructions cause the controller to disable the operation of the one or more components of the gate system.

In an embodiment of the invention, the method further includes receiving, from the dispatch server, a message indicating that the operation of the at least one component of the one or more components of the gate system is to be re-enabled. The message is received based on expiration of a predefined timer indicating a maximum permissible duration for completing a maintenance task associated with the service request. In this embodiment, the method further includes providing, to the controller, instructions indicating to re-enable the operation of the one or more components of the gate system.

In another embodiment of the invention, the plurality of processors of the jumper panel include a first processor and a second processor. In this embodiment, determining whether to grant the service request includes determining, by the first processor, to grant the service request, and determining, by the second processor, to grant the service request. In this embodiment, the method further includes comparing, by first processor and the second processor, a decision of the first processor to grant the service request and a decision of the second processor to grant the service request. In this embodiment, the method further includes granting, by the first processor and the second processor, the service request based on the first processor and the second processor independently determining to grant the service request.

In another embodiment of the invention, the plurality of processors of the jumper panel include a first processor and a second processor. In this embodiment, determining whether to grant the service request includes determining, by the first processor, to grant the service request, and determining, by the second processor, to deny the service request. In this embodiment, the method further includes comparing, by first processor and the second processor, a decision of the first processor to grant the service request and a decision of the second processor to deny the service request. In this embodiment, the method further includes denying, by the first processor and the second processor, the service request based on the first processor and the second processor independently determining different grant-denial decisions. In this embodiment, the method further includes performing, by at least one of the first processor and the second processor, one or more actions to report and/or correct an error that caused the first processor and the second processor to determine different grant-denial decisions.

In another embodiment of the invention, the plurality of processors of the jumper panel include a first processor and a second processor. In this embodiment, determining whether to grant the service request includes determining, by the first processor, to deny the service request, and determining, by the second processor, to deny the service request. In this embodiment, the method further includes comparing, by first processor and the second processor, a decision of the first processor to deny the service request and a decision of the second processor to deny the service request. In this embodiment, the method further includes denying, by the first processor and the second processor, the service request based on the first processor and the second processor independently determining to deny the service request.

In another embodiment of the invention, the method further includes providing, for display on a user interface of the jumper panel, a selectable representation of the segment of the track in a manner that depicts a relative geographic location of the segment relative to geographic locations of other segments of other tracks which are also selectable via the user interface.

In another embodiment of the invention, the method further includes authenticating, by each of the plurality of processors, a maintenance worker submitting the service request. In this embodiment, determining whether to grant the service request includes determining whether to grant the service request based on whether the authentication is successful.

In another aspect of the invention, a method is provided for controlling one or more components of a gate system located at a railroad crossing. The method includes receiving, by at least one processor of a plurality of processors of a jumper panel located in an equipment enclosure, a track selection signal indicative of a service request to disable operation of the one or more components of the gate system. The method further includes receiving, by at least one of the plurality of processors, track condition data from one or more track monitoring devices. The method further includes determining, by the at least one processor, track status data indicating operational safety conditions for a segment of track corresponding to the one or more components of the gate system. The track status data is determined based on the track condition data. The method further includes determining, by each of the plurality of processors, whether the one or more components of the gate system satisfy predefined safety criteria based on the track status data. The method further includes determining, by each of the plurality of processors, whether to grant the service request based on whether the one or more components of the gate system satisfy the predefined safety criteria. The method further includes providing, by the at least one processor, the service request to a dispatch server. The method further includes receiving, by the at least one processor, an approval message from the dispatch server. The approval message indicates to disable the operation of the one or more components of the gate system. The method further includes providing, by the at least one processor and to a controller configured to operate the one or more components of the gate system, instructions indicating to disable the operation of the one or more components of the gate system.

In an embodiment of the invention, the method further includes receiving, by at least one of the plurality of processors, a message from the dispatch server indicating that the operation of the at least one component of the one or more components of the gate system is to be re-enabled. In this embodiment, the method further includes providing, by at least one of the plurality of processors, instructions indicating to re-enable the operation of the one or more components of the gate system.

In another embodiment of the invention, the plurality of processors of the jumper panel include a first processor and a second processor. In this embodiment, determining whether to grant the service request includes determining, by the first processor, to grant the service request, and determining, by the second processor, to grant the service request. In this embodiment, the method further includes comparing, by first processor and the second processor, a decision of the first processor to grant the service request and a decision of the second processor to grant the service request. In this embodiment, the method further includes granting, by the first processor and the second processor, the service request based on the first processor and the second processor independently determining to grant the service request.

In another embodiment of the invention, the plurality of processors of the jumper panel include a first processor and a second processor. In this embodiment, determining whether to grant the service request includes determining, by the first processor, to grant the service request, and determining, by the second processor, to deny the service request. In this embodiment, the method further includes comparing, by first processor and the second processor, a decision of the first processor to grant the service request and a decision of the second processor to deny the service request. In this embodiment, the method further includes denying, by the first processor and the second processor, the service request based on the first processor and the second processor independently determining different grant-denial decisions. In this embodiment, the method further includes performing, by at least one of the first processor and the second processor, one or more actions to report and/or correct an error that caused the first processor and the second processor to determine different grant-denial decisions.

In another embodiment of the invention, the plurality of processors of the jumper panel include a first processor and a second processor. In this embodiment, determining whether to grant the service request includes determining, by the first processor, to deny the service request, and determining, by the second processor, to deny the service request. In this embodiment, the method further includes comparing, by first processor and the second processor, a decision of the first processor to deny the service request and a decision of the second processor to deny the service request. In this embodiment, the method further includes denying, by the first processor and the second processor, the service request based on the first processor and the second processor independently determining to deny the service request.

In another embodiment of the invention, the method further includes providing, for display on a user interface of the jumper panel, a selectable representation of the segment of the track in a manner that depicts a relative geographic location of the segment relative to geographic locations of other segments of other tracks which are also selectable via the user interface.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various embodiments of the invention and, together with the general description of the invention given above, and the detailed description of the embodiments given below, serve to explain the embodiments of the invention.

FIG. 1 is a diagram showing a conventional railroad communication system.

FIG. 2 is a diagram showing conventional signal equipment used in the conventional railroad communication system.

FIG. 3 is a diagram of an example environment in which systems, devices, and/or methods described herein may be implemented.

FIG. 4 is a diagram of example components of one or more devices of FIG. 3.

FIG. 5A is a diagram showing a maintenance worker interacting with a jumper panel to submit a service request and further showing processors of the jumper panel performing an authentication and/or validation check.

FIG. 5B is a diagram showing the processors of the jumper panel determining whether to grant the service request by using predefined safety criteria to process track condition data.

FIG. 5C is a diagram showing the processors of the jumper panel independently determining to deny the service request and displaying an indication of the denial of the service request via a user interface.

FIG. 5D is a diagram showing a first processor determining to grant the service request, a second processor determining to deny the service request, the processors performing cross verification to detect a conflict in the grant-denial decisions, and performing one or more actions to report and/or correct an error that caused the conflict in the grant-denial decisions.

FIG. 5E is a diagram showing the processors of the jumper panel independently determining the grant the service request and providing the service request to a crossing prediction controller.

FIG. 5F is a diagram showing the crossing prediction controller communicating with a dispatch center to obtain service request approval and communicating with a crossing controller to cause the crossing controller to disable operation of one or more components of a gate system.

FIG. 6 is a diagram of an example interface of the jumper panel.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 is a diagram showing a conventional railroad communication system 10. Communication system 10 includes a railroad crossing equipment housing 12 and a railroad dispatch center 14 that communicate over a network 16. The railroad crossing equipment housing 12 may be the physical location where one or more bypass jumpers are applied while performing a maintenance task. The railroad dispatch center 14 serves as a centralized traffic control (CTC) dispatch center that coordinates train movements and receives maintenance-related notifications via network 16.

In conventional systems, maintenance workers manually apply one or more bypass jumpers inside the railroad crossing equipment housing 12 to override control signals and hold warning equipment in a permissive state while performing a maintenance task. These bypass jumpers are simply conductive cables or wires with clips that physically connect terminals or relay points, thereby bypassing relay logic or other control circuitry. Communication between the railroad crossing equipment housing 12 and the railroad dispatch center 14 occurs over existing train control protocols, allowing dispatch personnel to receive notifications or grant authorization for maintenance. Maintenance tasks in conventional systems are often governed by railroad jumper policies that require proper documentation and supervisory permission before manually applying bypass jumpers.

FIG. 2 shows conventional signal equipment 18, including warning equipment 20, a house battery 22, and a highway grade crossing warning device (HGCWD) 24. The warning equipment 20 may include relay contacts, gate actuators, flashing light circuits, and/or similar control devices. The house battery 22 may include one or more rechargeable or non-rechargeable battery banks designed to supply operating voltage to crossing control equipment in the event of power failure or during maintenance. The highway grade crossing warning device 24 may include crossing gates, flashing light signals, audible warning bells, signage, and/or other safety-related devices intended to warn motorists and pedestrians of approaching trains. As shown in FIG. 2, solid lines represent the normal circuit paths through which the house battery 22 supplies power via the highway grade crossing warning device 24 to the warning equipment 20 during standard operation. Dashed lines in FIG. 2 illustrate the application of bypass jumpers connecting the house battery 22 directly to the warning equipment 20, thereby paralleling or circumventing the control path through the highway grade crossing warning device 24.

The current railroad jumper policies effectively negate the control signals from relay contacts and other controlling devices, holding crossing gates in a non-fail safe position (e.g., crossing gate arm up). Under these policies, maintenance workers must obtain verbal pre-authorization and then manually install bypass jumper cables that physically connect the house battery 22 directly to the warning equipment 20. This jumper application bypasses and circumvents the control circuitry of the HGCWD 24, forcing the warning equipment 20 to remain energized in a permissive state even if track occupancy is detected. However, this process is inherently unsafe. For example, the maintenance worker may skip the step of pre-authorization (e.g., intentionally or unintentionally, may accidentally apply jumper cables to the wrong track circuit, or may forget to remove the jumper cables after completing maintenance (e.g., to restore normal gate operation). These failures can lead to serious safety hazards, including the potential for serious injury, environmental damage, and even loss of life.

FIG. 3 is a diagram of an example environment 26 in which systems and/or methods described herein may be implemented. As shown in FIG. 3, example environment 26 may include equipment housing 28 (sometimes referred to as an equipment enclosure) which includes a jumper panel 30 and a crossing prediction device 32, a crossing controller 34, a track monitoring device 36, a dispatch center server 38, a gate system 40, and/or a network 42. Devices of example environment 26 may interconnect via wired connections, wireless connections, or a combination of wired and wireless connections.

Jumper panel 30 includes one or more devices configured to receive, store, process, and/or provide information associated with a service request. For example, the jumper panel 30 may include a device such as a control panel, an industrial logic cabinet, a railway interlocking interface unit, a track-side microcontroller unit, a field signaling enclosure, or a similar type of railway infrastructure device. A service request, as used herein, refers to a request submitted by a maintenance worker to disable one or more components of gate system 40 located at a railroad crossing.

Jumper panel 30 may communicate with one or more other devices in example environment 26 using one or more communication protocols or methods suitable for safety-critical, low-latency, and/or supervisory control messaging. These communication protocols or methods may include a binary messaging protocol, a serial communication protocol, a wired or wireless industrial networking standard, a fieldbus-based interface, and/or the like. For example, the jumper panel 30 may communicate using a Genisys protocol, which is a low-data-rate, binary communication protocol supporting message duplication (e.g., 1oo2D, 2oo3, etc.), message acknowledgment, and error detection.

To provide another example, the jumper panel 30 may communicate using an RS-232 or RS-485 serial communication protocol for reliable point-to-point or multi-drop field communication. To provide another example, the jumper panel 30 may communicate using a CAN bus or Modbus for industrial device-to-device communication. To provide another example, the jumper panel 30 may communicate using Ethernet/IP, TCP/IP, and/or UDP/IP, for high-level data communication with central control systems or networked equipment. To provide another example, the jumper panel 30 may communicate using a wireless communication protocol, such as cellular (e.g., LTE), Wi-Fi, or licensed radio for redundant or remote supervisory messaging. To provide another example, the jumper panel 30 may communicate using a vital signaling-specific protocol, including standards-based safety-certified messaging layers used in railway interlockings or Positive Train Control (PTC) environments.

Crossing prediction device 32 includes one or more devices configured to receive, store, process, and/or provide information associated with the service request and/or information associated with a status or availability of a segment of a track that intersects the railroad crossing. For example, the crossing prediction device 32 may include a computing device, such as a device with a railway-grade prediction module, a wayside computing device, a track signal processing unit, or a similar type of signal processing or field-deployed computing device.

The crossing prediction device 32 may communicate with one or more other devices in example environment 26 using one or more communication protocols suitable for transmitting safety-relevant status information, predictive analytics, control instructions, and request/response messages. These communication methods may support both deterministic safety-critical exchanges and higher-bandwidth supervisory or diagnostic data. For example, the crossing prediction device 32 may communicate using a Genisys protocol for transmitting and receiving binary control messages, status indications, and acknowledgments to or from the jumper panel 30 or dispatch center server 38, with support for 1oo2D or 2oo3 redundancy, error detection, and/or message validation.

As another example, the crossing prediction device 32 may communicate using an RS-232 or RS-485 serial communication protocol for point-to-point or multi-device interfaces with field equipment such as motion detectors, relays, or older interlocking infrastructure. To provide another example, the crossing prediction device 32 may communicate using a CAN bus or Modbus for real-time polling of sensor values or interfacing with PLC-based field controllers. To provide another example, the crossing prediction device 32 may communicate using Ethernet/IP, TCP/IP, and/or UDP/IP for exchanging predictive analytics, service request validation messages, or confirmation signals with dispatch servers or external monitoring systems. To provide another example, the crossing prediction device 32 may communicate using a wireless communication protocol, such as licensed radio, Wi-Fi, or cellular (e.g., LTE, 5G) for cloud integration or redundant supervisory control. To provide another example, the crossing prediction device 32 may communicate using a vital railroad protocol, such as a protocol compliant with (PTC, CENELEC safety messaging standards, or another SIL-rated signaling framework.

In some embodiments, the crossing prediction device 32 may be configured with a custom vital safety application. In this case, the crossing prediction device 32 may use the custom vital safety application to perform one or more validation checks and/or one or more other safety related checks described herein.

In some embodiments, functionality described herein as being performed by the crossing prediction device 32 may be performed by the jumper panel 30. For example, functionality described herein as being performed by a processor of the crossing prediction device 32 may be performed by a processor of the jumper panel 30. To provide a specific example, assume the jumper panel 30 includes two processors configured to implement various redundant safety checks, including an authentication check, a validation check, and/or a verification check. In some embodiments, the jumper panel 30 may further include a third processor configured to perform the functionality described herein as being performed by the processor of the crossing prediction device 32. In other embodiments, the two processors performing the redundant safety checks may each perform the functionality described herein as being performed by the processor of the crossing prediction device 32.

Crossing controller 34 includes one or more devices configured to control operation of one or more components of the gate system 40. For example, the crossing controller 34 may include a field controller, an electromechanical relay controller, a motor drive circuit, or an industrial control unit with I/O interfaces connected to crossing gate actuators, and/or the like. Crossing controller 34 may control operation of one or more components of the gate system 40 by sending instructions that cause actuation of a railroad crossing gate (e.g., causing the gate to lower, to raise, etc.), instructions that cause a visual alert to be displayed on a lighting component, instructions that activate an audible alert, and/or the like. While shown as separate from the gate system 40, this is done for illustrative purposes, and in practice, the crossing controller 34 may be implemented as part of the gate system 40.

Track monitoring device 36 includes one or more devices configured to detect the presence and/or absence of a rail vehicle and/or to detect a motion and/or speed of the rail vehicle relative to a segment of railroad track. For example, track monitoring device 36 may include a motion detector, a Doppler radar sensor, a wheel sensor, an axle counter, a track circuit, a shunt-based presence detector, and/or the like. In some embodiments, track monitoring device 36 may communicate with the crossing prediction device 32 and/or jumper panel 30 via a wired or wireless network or another communication interface and/or protocol described herein.

Dispatch center server 38 includes one or more devices configured to receive, store, process, and/or provide information associated with a service request. For example, dispatch center server 38 may include a server device (e.g., a host server, a web server, an application server, etc.), a data center device, or a similar device. The dispatch center server 38 may communicate with the crossing prediction device 32 and/or the jumper panel 30 via the network 42.

Gate system 40 includes one or more devices configured to provide active warning or control functionality at a railroad crossing. For example, gate system 40 may include a railroad crossing gate arm, one or more actuator mechanisms, one or more wiring harnesses, one or more control relays, one or more flashing lights, an audible warning device (e.g., a speaker, a bell, etc.), and/or the like. The active warning or control functionality may, for example, include operating the railroad crossing gate arm to obstruct or permit vehicle passage at a railroad crossing, operating the one or more flashing lights, operating the audible warning device, and/or the like. In some embodiments, the crossing controller 34 may provide, to the gate system 40, signals and/or instructions capable of disabling or enabling one or more components of the gate system 40. In some embodiments, one or more devices described herein may be part of a highway-rail grade crossing warning system (HRGCWS).

In some embodiments, one or more other devices may communicate with the devices described above. For example, a user device of a maintenance worker (e.g., a mobile device, a laptop computer, etc.) may be configured to communicate with one or more devices described herein.

Network 42 includes one or more wired and/or wireless networks. For example, network 42 may include a cellular network (e.g., a fifth generation (5G) network, a fourth generation (4G) network, such as a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, a cloud computing network, or the like, and/or a combination of these or other types of networks. In some embodiments, network 42 may include a fiber optic line, Ethernet connection, cellular communication module, radio modem, a secure virtual private network (VPN) tunnel over the Internet, and/or the like.

In some embodiments, devices of environment 26 may provide indirect control using the crossing prediction device 32. In such an embodiment, functionally safe “vital” hardware and software may be implemented in the jumper panel 30 and a custom vital application may be implemented using the crossing prediction device 32. The jumper panel 30, when used in tandem with a custom vital application that runs in the crossing prediction device 32, ensures that all aspects of taking tracks out of service are safe. The jumper panel 30 may be configured with redundant forms of authentication and/or validation to authenticate and/or validate a service request provided by an authorized maintenance worker. The jumper panel 30 may also securely communicate the service request to the dispatch center server 38, such as by providing the service request to the crossing prediction device 32 which then provides the service request to the dispatch center server 38. Upon receipt of an approval message from the dispatch center server 38, the crossing prediction device 32 may orchestrate disabling service of one or more components of the gate system 40 in a manner consistent with that indicated in the received approval message. After the required maintenance is complete, the authorization for the service request is rescinded and the dispatch center server 38 updates a local data structure or database with data indicating that the approval of the service request has been rescinded. At this point, the one or more components of the gate system 40 are returned to a normal, active operating state.

In some embodiments, devices of environment 26 may provide direct control using a motion detector input or relay provided by track monitoring device 36. A motion detector input is a signal received from the track monitoring device 36 (e.g., a trackside sensor) that indicates whether rail vehicle motion is present within a defined detection zone, enabling the system to verify track occupancy status in real-time before authorizing maintenance operations. A relay wrap is a technique where the circuit is temporarily bypassed around relay contacts to hold crossing gates in a permissive state during maintenance. In this embodiment, functionally safe “vital” hardware and software may be implemented in the jumper panel 30. Further, in this embodiment, there is no crossing prediction device 32, and instead, the jumper panel 30 serves as a central signal command and communications hub. Under normal operating conditions, the jumper panel 30 receives input from track monitoring device 36, receives a service request from a maintenance worker, authenticates and/or validates the service request, communicates with the dispatch center server 38 to obtain an approval message, and provides instructions to the crossing controller 34 to disable operation of the one or more components of the gate system 40. After the required maintenance is complete, the authorization for the service request is rescinded and the dispatch center server 38 updates a local data structure or database with data indicating that the approval of the service request has been rescinded. At this point, the one or more components of the gate system 40 are returned to a normal, active operating state. A detailed description of these processes is provided in connection with the description of FIGS. 5A-5F.

The number and arrangement of devices and networks shown in FIG. 3 are provided as an example. In practice, there may be additional devices and/or networks, fewer devices and/or networks, different devices and/or networks, or differently arranged devices and/or networks than those shown in FIG. 3. For example, devices of environment 26 may exclude the track monitoring device 36 while including the crossing prediction device 32, may include the track monitoring device 36 while excluding the crossing prediction device 32, and so forth. Furthermore, two or more devices shown in FIG. 3 may be implemented within a single device, or a single device shown in FIG. 3 may be implemented as multiple, distributed devices. Additionally, or alternatively, a set of devices (e.g., one or more devices) of environment 26 may perform one or more functions described as being performed by another set of devices of environment 26. For example, the jumper panel 30 may be configured to perform one or more functions described as being performed by the crossing prediction device 32.

FIG. 4 is a diagram of example components of a device 44. Device 44 may correspond to the jumper panel 30, the crossing prediction device 32, the crossing controller 34, the track monitoring device 36, the dispatch center server 38, and/or the gate system 40. In some embodiments, the jumper panel 30, the crossing prediction device 32, the crossing controller 34, the track monitoring device 36, the dispatch center server 38, and/or the gate system 40 may include one or more devices 44 and/or one or more components of device 44. As shown in FIG. 4, device 44 may include a bus 46, a processor 48, a memory 50, a storage component 52, an input component 54, an output component 56, and/or a communication interface 58.

Bus 46 includes a component that permits communication among multiple components of device 44. Processor 48 is implemented in hardware, firmware, and/or a combination of hardware and software. Processor 48 includes a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, programmable logic controller (PLC), a digital signal processor (DSP), an embedded processor, a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a system-on-module (SOM), and/or another type of processing component. In some embodiments, processor 48 includes one or more processors capable of being programmed to perform a function. In some embodiments, bus 46 may include multiple processors 48 so as to improve railroad safety through redundancy or duplicative processing as is described elsewhere herein. Memory 50 includes a random-access memory (RAM), a read only memory (ROM), and/or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and/or an optical memory) that stores information and/or instructions for use by processor 48.

Storage component 52 stores information and/or software related to the operation and use of device 44. For example, storage component 52 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and/or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and/or another type of non-transitory computer-readable medium, along with a corresponding drive.

Input component 54 includes a component that permits device 44 to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and/or a microphone). Additionally, or alternatively, input component 54 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and/or an actuator). Output component 56 includes a component that provides output information from device 44 (e.g., a display, a speaker, and/or one or more light-emitting diodes (LEDs)).

Communication interface 58 includes a transceiver-like component (e.g., a transceiver and/or a separate receiver and transmitter) that enables device 44 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communication interface 58 may permit device 44 to receive information from another device and/or provide information to another device. For example, communication interface 58 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, an application programming interface (API), and/or the like.

Device 44 may perform one or more processes described herein. Device 44 may perform these processes based on processor 48 executing software instructions stored by a non-transitory computer-readable medium, such as memory 50 and/or storage component 52. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space spread across multiple physical storage devices.

Software instructions may be read into memory 50 and/or storage component 52 from another computer-readable medium or from another device via communication interface 58. When executed, software instructions stored in memory 50 and/or storage component 52 may cause processor 48 to perform one or more processes described herein. Additionally, or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, embodiments described herein are not limited to any specific combination of hardware circuitry and software.

The number and arrangement of components shown in FIG. 4 are provided as an example. In practice, device 44 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 4. Additionally, or alternatively, a set of components (e.g., one or more components) of device 44 may perform one or more functions described as being performed by another set of components of device 44.

FIGS. 5A-5F illustrate an example method 60 for controlling one or more components of the gate system 40. Gate system 40 may be located at a railroad crossing. The jumper panel 30, the crossing prediction device 32, the crossing controller 34, the track monitoring device 36, and/or the dispatch center server 38 may be part of a system used to control the one or more components of the gate system 40. The railroad crossing may be a grade crossing, e.g., a point at which the railroad intersects with a roadway or highway. The system may, in some embodiments, be an HRGCWS.

In some embodiments, such as that shown in FIGS. 5A-5F, the jumper panel 30 may be configured with two processors 48, such as processor 48-1 and processor 48-2. As will be shown, the jumper panel 30 provides an additional layer of safety and redundancy by having two independent processors that can each perform safety checks, execute service request validation logic, and cross-verify their results before authorizing any maintenance action. This two-processor configuration supports a 1oo2D (one out of two) voting architecture, which can be used to achieve a functional safety level often characterized as safety integrity level (SIL) 2, where both processors operate independently to perform the same safety function while continuously comparing outputs.

In other embodiments, only one processor 48 may be implemented, offering simpler control but with reduced safety redundancy. In other embodiments, three or more processors 48 may be implemented. For example, three processors 48 may be implemented to support a 2oo3 (two out of three) voting architecture, which may be used to achieve SIL 3 functional safety integrity. In a 2oo3 configuration, three processors 48 perform the same safety function independently and vote on the result. The system accepts the majority decision (at least two matching results) while tolerating a single processor fault without losing availability or safety integrity. This higher level of redundancy improves fault detection and resilience against common-cause failures, enabling safer operation even in the presence of certain faults. Notably, the processors providing redundancy (e.g., in a 1oo2d configuration, in a 2oo3 configuration, etc.) can be implemented in a number of different ways. For example, the processors may be implemented in a parallel configuration, a serial configuration, or even a hybrid configuration.

As shown in FIG. 5A, and by reference number 62, a maintenance worker may submit a service request to perform maintenance on one or more components of the gate system 40 that need to be temporarily taken out of service. For example, the maintenance worker may interact with a selection interface of the jumper panel 30 to select a segment of a track that corresponds to the one or more components of the gate system 40 targeted for temporary deactivation. The selection interface may be a user interface and/or a series of mechanical buttons or switches.

In some embodiments, the selection interface may be a user interface that displays selectable representations of segments of tracks that intersect or run perpendicular to the roadway or highway. Each selectable representation of a segment is capable of being selected by the maintenance worker to initiate a service request.

The service request may include data such as the selected track identifier, a timestamp, service request type data indicating a type of service request, timing parameters indicating a time at which the service request is intended to begin and/or a duration at which one or more components of the gate system 40 are requested to be taken out of service, and/or the like. The data indicating the type of service request may include data indicating a track out-of-service request, a crossing gate hold-up request, a test mode activation request, a sensor bypass request, a communications channel diagnostic request, a power supply override or monitoring request, and/or the like. The track out-of-service request may be submitted to disable automatic crossing protection (e.g., gate activation, warning lights, etc.) for a specific track segment to allow the maintenance worker to perform a maintenance task. A crossing gate hold-up request may be submitted to request to hold the crossing gate up in a permissive position for a defined duration or until a maintenance task is completed. A test activation mode request may place one or more components of gate system 40 into a diagnostic test state to verify proper functionality without triggering a full warning sequence (e.g., run gate lamp test on Track 1).

A sensor bypass request may temporarily disable one or more input sensors (e.g., motion detectors, track circuits, etc.) if these input sensors have been generating inaccurate data or are subject to a mandatory maintenance check. A communications channel diagnostic request may initiate a protocol test with the dispatch center server 38 or crossing prediction device 32 to verify the health of the communication link. A power supply override or monitoring request may allow viewing or temporarily bypassing power faults or battery issues for non-vital components during inspection.

In some embodiments, the user interface may display a graphical map or a schematic of a crossing layout of the railroad crossing. The graphical map or schematic may include selectable representations of multiple track segments (e.g., track 1, track 2, siding A, yard lead, mainline B, etc.), color-coded or icon-based status indicators (e.g., green for idle, red for occupied, gray for unavailable, etc.), and/or the like. Such visual indicators may help the maintenance worker quickly assess track occupancy and system status before submitting a service request.

Additionally, or alternatively, the user interface may display a real-time track status overlay data received from crossing prediction device 32 and/or the track monitoring device 36. This overlay may show information such as detection of a rail vehicle on a track, motion detected in a defined zone, track circuit health, sensor fault statuses, and/or the like. Additionally, or alternatively, the user interface may display security and validation feedback, such as by displaying a visual indicator to confirm whether an authentication check succeeded, whether a current track status has been validated, and/or the like. Additionally, or alternatively, the user interface may also include a service request panel where the maintenance worker can view service request history, submit new service requests, monitor outcomes of pending requests, and/or review logs. Additionally, or alternatively, the user interface may provide a geographic overview that shows the relative locations of track segments that intersect or are located near the railroad crossing to aid in proper identification and selection.

Additionally, or alternatively, the selection interface may be a series of mechanical buttons or switches. For example, the jumper panel 30 may include dedicated, labeled toggle switches or push buttons corresponding to specific track segments or maintenance functions. The maintenance worker may physically actuate these switches to select the desired track segment and initiate the service request. Such mechanical controls may be preferred in environments requiring rugged, simple, or highly tactile interfaces that remain operable under harsh weather conditions or when gloved operation is necessary.

As shown by reference number 64, when the maintenance worker selects the segment of track that needs to be temporarily taken out of service, a track selection signal is generated and provided to the jumper panel 30. For example, the track selection signal may be delivered to each of processors 48-1 and 48-2. By implementing multiple processors, the jumper panel 30 improves safety through redundancy and cross-verification. For example, if an issue arises that affects one of the processors, the resulting discrepancy between the outputs of the two processors can be detected, enabling the jumper panel 30 to initiate appropriate fault handling or corrective actions. These processes are described in further detail in connection with FIGS. 5C-5E.

As shown by reference number 66, the processors 48-1, 48-2 may perform an authentication check and/or a validation check. For example, the processors 48-1, 48-2 may use the track selection signal to perform an authentication check of the maintenance worker and/or to perform a validation check of the maintenance worker. Authentication refers to verifying the identity of the maintenance worker. The jumper panel 30 can perform an authentication check by performing a radio frequency identification (RFID) badge scan, processing a password input, performing biometric recognition, and/or the like. Validation refers to confirming the presence or physical engagement of the maintenance worker, without necessarily identifying them, which may be used when the jumper panel 30 is configured with a physical push button, a footswitch, a touch-sensitive interface, a proximity or contact sensor, and/or the like. Example embodiments are provided below.

In some embodiments, each processor 48-1, 48-2 may authenticate the maintenance worker. For example, each processor 48-1, 48-2 may access an authentication module stored in memory, which is configured to verify credentials received via the user interface. The user interface may include an RFID badge reader that scans an electronic maintenance ID badge associated with an authorized maintenance worker. Each processor may then compare the scanned badge ID with an access control list stored locally or provided from the dispatch center server 38. Additionally, or alternatively, the user interface may be configured to accept a user-provided password or biometric input, such as a fingerprint scan, and to match the user-provided password or biometric input against stored authentication templates. In a dual-processor architecture, both processors independently authenticate the maintenance worker and compare results to ensure a matching outcome. If authentication fails or if the results differ between processors, the service request is denied and a fault state may be logged and/or displayed on the user interface.

Additionally, or alternatively, each processor 48-1, 48-2 may validate the presence of the maintenance worker. For example, the user interface of the jumper panel 30 may include a hardware-based validation input such as a spring-loaded footswitch, physical lever, or press-to-confirm push button. Activation of this input causes a hardware signal to be transmitted to each of the processors 48-1, 48-2. Each processor 48-1, 48-2 monitors a designated validation input channel and records the event along with a time stamp. Validation may also occur via a proximity or capacitive touch sensor that detects a maintenance workers physical engagement with the panel, confirming that the maintenance worker is physically present and interacting with the system. This form of validation does not confirm identity but instead confirms physical presence and engagement as a precondition for initiating or approving a service request. As with authentication, validation results are compared between the two processors to ensure consistency, thereby improving overall safety of the system.

Additionally, or alternatively, each processor 48-1, 48-2 may validate the service request. For example, upon receiving the track selection signal, each processor 48-1, 48-2 may retrieve a locally stored configuration table that defines valid track identifiers and any associated constraints (e.g., which track segments are eligible for removal from service at a given location). The service request may include the selected track identifier, a timestamp, and a request format code. Each processor 48-1, 48-2 verifies that the track identifier is present in the configuration table, that the request format conforms to the expected protocol structure, and that local policy rules (e.g., “no concurrent out-of-service requests”) are satisfied. This local validation allows the jumper panel 30 to pre-filter an impermissible or invalid service request without relying solely on remote systems. If either processor 48-1, 48-2 detects an impermissible or invalid service request, a fault indication may be triggered, and the service request may be denied.

Additionally, or alternatively, each processor 48-1, 48-2 may perform a system safety check to confirm that the system is in a non-faulted state. For example, each processor 48-1, 48-2 may monitor a set of safety-critical input signals, such as heartbeat messages from internal software watchdogs, power supply integrity, relay state confirmations, environmental sensor inputs (e.g., door tamper switches, panel temperature, etc.), and/or the like. A heartbeat message refers to a periodic signal or flag that the is sent to indicate that a particular component or device or operating properly. A software watchdog refers to a monitoring routine that continuously checks whether certain components (e.g., processor loops, task schedulers, communication stacks, etc.) are functioning correctly within timing constraints. One or more of these inputs may be part of a dedicated “vital input” subsystem monitored in real-time. The processors 48-1, 48-2 may also perform self-diagnostic routines to check memory integrity, clock synchronization, and cross-channel redundancy consistency. Results of these diagnostics are shared between the processors 48-1, 48-2 and checked for consistency. If either processor detects a fault condition or if the processors 48-1, 48-2 reach inconsistent conclusions, the system may enter a safe state and deny the service request. Optionally, a fault output line (e.g., a de-energize-to-safe 12V digital output) may be driven low or activated by the processors 48-1, 48-2 to indicate a system level fault. This output line may be directly wired to the crossing controller 34 to trigger an immediate transition to a safe state (e.g., lowering the crossing gates) upon detection of a fault condition.

In some embodiments, the jumper panel 30 (e.g., using one or more memories 50, one or more storage components 52, etc.) may store a track identifier or track segment identifier corresponding to the segment of the track that has been selected for the service request. Additionally, or alternatively, the jumper panel 30 may store a result of an authentication check and/or a validation check.

In this way, the jumper panel 30 ensures fault tolerance, enhances system reliability, and supports compliance with functional safety standards (e.g., SIL 2) by requiring independent agreement between multiple processors for authentication and/or validation, thereby reducing the risk of single-point failure, accidental authorization, or malicious bypass of safety procedures.

As shown in FIG. 5B, and by reference number 68, the track monitoring device 36 may generate and provide track traffic data to the crossing prediction device 32. The track traffic data may include vehicle presence data indicating a presence of a rail vehicle at a crossing, speed data indicating a speed of a rail vehicle on a track, data indicating a direction of movement of a rail vehicle, timestamp data, and/or the like. The track condition data may be raw sensor outputs or semi-processed data, and may originate from one or more track monitoring devices, including motion detectors, axle counters, wheel sensors, and/or the like.

To provide the track traffic data to the crossing prediction device 32, the track monitoring device 36 may be electrically or wirelessly connected to the crossing prediction device 32 via a hardwire serial interface (e.g., RS-485, CAN bus), a digital input/output (I/O) module, or a network-based protocol (e.g., Ethernet/IP or Modbus TCP). In some embodiments, the track traffic data may be provided at configured intervals or provided asynchronously in response to a detected event, such as the presence of a rail vehicle.

Additionally, or alternatively, the track monitoring device 36 may generate and provide sensor health status data to the crossing prediction device 32. Health status data refers to diagnostic or self-monitoring data indicating whether the sensors of device 36 are operating properly, data indicating faults or anomalies in sensor performance, internal diagnostic codes or conditions, and/or the like.

As shown by reference number 70, the crossing prediction device 32 may determine track status data based on the track traffic data. The track status data may include data indicating an estimated time of arrival of a rail vehicle, data indicating a predicted occupancy window for one or more track segments, data indicating a track segment conflict flag, a decision grade output (e.g., a quantified likelihood that the track is clear for servicing), data indicating a predicted clearance time, data indicating a grant-deny recommendation for a service request, and/or the like.

In some embodiments, the crossing prediction device 32 may use a rules engine or machine-learning model trained on prior crossing data to process the received track traffic data and to generate corresponding track status data. The track status data may reflect current operational safety conditions and/or anticipated future states of the track segment being targeted for maintenance and/or one or more other adjacent or nearby track segments that cross the railroad crossing. For example, the crossing prediction device 32 may determine an estimated time of arrival (ETA) of a rail vehicle by analyzing track traffic data such as detected vehicle speed, distance from the crossing, and direction of movement, and/or by applying physics-based motion prediction models or statistical regression models trained on historical arrival times.

In some embodiments, the predicted occupancy window for one or more track segments may be determined by combining ETA calculations with typical train length profiles and speed decay models to estimate how long the rail vehicle will occupy each segment, outputting time intervals during which maintenance should be prohibited. A track segment conflict flag may be computed by cross-referencing planned or predicted train paths with current service request parameters, identifying any geographic or temporal overlaps between the requested out-of-service segment and other segments known to be occupied, predicted to be occupied, or already reserved by other authorizations.

A decision grade output (e.g., a quantified likelihood that the track is clear for servicing) may be computed by combining and analyzing multiple traffic data inputs, such as presence detection confidence scores, recent sensor history, motion dwell times, and sensor health status. These inputs may be analyzed using a rules-based weighting system or a probabilistic model to produce a numerical score representing an overall safety confidence level. A predicted clearance time may be determined by modeling train dynamics based on measured speed, direction, and known deceleration patterns, predicting when the rail vehicle will fully clear the relevant track segment or crossing zone. Finally, the grant-deny recommendation for a service request may be generated by applying configured safety rules that consider all computed parameters, such as denying a request if any conflict flag is set, if the ETA is within a configured buffer window, or if the decision grade score is below a safety threshold, thereby providing a machine-enforceable safety recommendation to the jumper panel processors.

As shown by reference number 72, the crossing prediction device 32 may provide the track status data to the jumper panel 30. For example, the crossing prediction device 32 may communicate with the jumper panel 30 via a secure, low-latency communication protocol such as Genisys, Ethernet/IP, or a proprietary safety-rated interface. The track status data may be transmitted as redundant message pairs, which are independently received and validated by each of the processors 48-1 and 48-2 of the jumper panel 30. Each processor 48-1, 48-2 may parse and verify the data, perform checksum validation, and/or confirm that the received track status data is consistent across the redundant communication channels. In this way, the processors 48-1, 48-2 provide synchronized decision-making while maintaining fault detection capabilities in line with SIL 2 design principles.

As shown by reference number 74, each processor 48-1, 48-2 may determine whether the track segment and associated gate system 40 components meet predefined safety criteria for granting the service request. For example, the processors 48-1, 48-2 may apply a safety rule engine to compare the received track status data against one or more predetermined conditions stored in local configuration memory. These conditions may include determining whether a rail vehicle is present, whether an estimated arrival time falls within a threshold time period (e.g., a safe buffer window), whether any track segment conflict flag is set, whether a system health status satisfies a configured threshold health status level, and/or the like. This determination step reflects the role of the processors 48-1, 48-2 in applying multi-factor safety logic based on both local checks (e.g., configuration table validation) and remote insights (e.g., predicted occupancy windows from the crossing prediction device 32) before granting the service request.

As shown by reference number 76, each processor 48-1, 48-2 may determine whether to grant the service request based on whether the gate system 40 and/or the corresponding track segment satisfies the predefined safety criteria. For example, each processor 48-1, 48-2 may evaluate received track status data and determine to grant the service request if no rail vehicle is detected on or approaching the selected track segment, if predicted occupancy windows fall outside configured safety buffer periods, if no conflict flags are set for adjoining track segments, if all local system health checks and interlock conditions are satisfied, and/or the like. Conversely, each processor 48-1, 48-2 may determine to reject the service request if any of these criteria indicate an unsafe condition, such as detection of an approaching train, insufficient clearance time, presence of conflicting track authorities, failure of local hardware or software health checks, and/or the like. This evaluation enables each processor 48-1, 48-2 to make an independent safety determination, thereby improving safety by introducing redundancy that would prevent a service request from being mistakenly granted due to a fault impacting the performance of one of the processors 48-1, 48-2.

The processors 48-1, 48-2 of the jumper panel 30 may independently determine to deny the service request, may make conflicting determinations as to whether to grant or deny the service request, or may both determine to grant the service request. FIGS. 5C-5E show the steps involved in example process 60 in each of these respective scenarios.

As shown in FIG. 5C, and by reference number 78, each of processors 48-1, 48-2 may independently determine to deny the service request. As shown by reference number 80, the processors 48-1, 48-2 may deny the service request based on a cross verification outcome whereby each processor 48-1, 48-2 independently determines to deny the service request. That is to say, the processors 48-1, 48-2 may compare their independently computed determinations to deny the service request and may collectively deny the service request after verifying that each processor 48-1, 48-2 came to the same decision. In this case, each processor 48-1, 48-2 may have an internal approval flag and may deny the service request by updating a state of the flag to a denied state to prevent the service request from being provided to the crossing prediction device 32 and/or to the dispatch center server 38.

In some embodiments, the processors 48-1, 48-2 may generate a record of the denial of the service request. The record may include data indicating that the service request has been denied, data describing a reasoning as to why the service request is denied, a service request identifier, a track segment identifier for the track segment linked to the service request, timestamp data, the track status data received data from the crossing prediction device 32, and/or the like.

In some embodiments, the processors 48-1, 48-2 may store the record of the denial of the service request. For example, the processors 48-1, 48-2, along with the corresponding memory 50, may store this record (e.g., using a corresponding memory 50) to create a local audit trail for maintenance safety reviews.

In some embodiments, each processor 48-1, 48-2 may transmit the record of the denial of the service request to the crossing prediction device 32 and/or to the dispatch center server 38. By reporting this record to one or more other devices in the system, the one or more other devices in the system may then be configured to create a centralized log of maintenance authorization attempts.

As shown by reference number 82, the jumper panel 30 may provide, for display on the user interface, an indication of the denial of the service request. For example, the user interface may display a colored warning icon (e.g., red, amber, etc.), illuminate a dedicated “Request Denied” laser emitting diode (LED), provide text such as a message stating “Service Request Denied—Track Not Clear”, emit an audible tone or buzzer to alert the maintenance worker, and/or the like. Such indications help ensure that the maintenance worker is immediately made aware of the denial decision, reducing the risk of unintended work on an active or unsafe track segment.

As shown in FIG. 5D, and by reference number 84, processor 48-1 may determine to grant the service request and processor 48-2 may determine to deny the service request. Next, the processors 48-1, 48-2 may perform cross verification to share their respectively determined decisions as to whether to grant or deny the service request. As shown by reference number 86, the processors 48-1, 48-2 may collectively determine to deny the service request based on the cross verification including conflicting grant-deny decisions. In this case, each processor 48-1, 48-2 may have an internal approval flag and may deny the service request by updating a state of the flag to a denied state to prevent the service request from being provided to the crossing prediction device 32 and/or to the dispatch center server 38.

As shown by reference number 88, the processors 48-1, 48-2 may perform one or more actions to report and/or correct an error causing conflicting grant-deny decisions. For example, each processor 48-1, 48-2 may generate and provide a diagnostic signal to one or more downstream devices in the system (e.g., crossing prediction device 32, crossing controller 34, dispatch center server 38, etc.). Each processor 48-1, 48-2 may actively control a dedicated output channel or communication line to provide this diagnostic conflict signal to one or more downstream devices in the system.

In one embodiment, the processors 48-1, 48-2 may set the electrical voltage on the output line to a predefined low or zero-volt level which one or more downstream devices are configured to interpret as a conflict condition. For example, each processor 48-1, 48-2 may set a dedicated digital output line from a high voltage level (e.g., 12 volts) to a low or zero voltage level specifically to indicate a fault state or unsafe condition. This de-energize-to-safe output is wired to other vital system components, such as relays or interlock circuits, to immediately trigger a safe shutdown, prevent further service request processing, or to hold the crossing gate system in a fail-safe position (e.g., gates down) until the fault is resolved.

In other embodiments, the diagnostic signal may represent digital data transmitted over a communication interface. This data may include information indicating that a conflict occurred, the specific nature of the conflict (e.g., where processors 48-1, 48-2 perform independent diagnostic analysis to identify the root cause), time stamp data, and/or the like. The conflict data may follow a fixed encoding scheme to support consistent reporting, logging, and automated system responses. In other embodiments, the conflict data may be conveyed as a single-bit or digital on/off signal (e.g., logic low=fault, logic high=normal) that can be directly interpreted by one or more downstream devices.

The diagnostic conflict signal may be provided to the crossing prediction device 32 and/or to the dispatch center server 38, thereby enabling other system devices to detect the conflict, log the conflict for maintenance records, trigger safety interlocks, block related service requests until the conflict is resolved, and/or perform other safety management actions.

Additionally, or alternatively, the processors 48-1, 48-2 may store a conflict record of the conflicting independently computed determinations in memory for subsequent maintenance review. For example, each processor 48-1, 48-2 may store in memory 50 a conflict record including data identifying the conflicting independently computed determinations, the service request identifier, the track segment identifier, timestamp data, received track status data, processor fault codes, and/or any relevant local configuration version information. Storing this information permits maintenance personnel to identify the cause of the discrepancy, supports auditing of safety-critical decision logic, and/or facilitates compliance with safety standards that require thorough record-keeping of fault conditions and validation errors.

In some embodiments, the processors 48-1, 48-2 may send the conflict record to the crossing prediction device 32 and/or to the dispatch center server 38 to ensure system-wide awareness of the discrepancy. The user interface may also display an error message or fault indication to inform the maintenance worker that the service request was denied due to an internal validation conflict. In some embodiments, the user interface may also display a reason as to why the service request was denied.

In some embodiments that employ additional redundancy (e.g., systems with three processors), a voting system may be used such that if two processors make the same determination as to whether to grant or deny the service request, while another processor makes a conflicting determination, the majority decision may be accepted and the service request may proceed. That said, in a dual-processor 1oo2D implementation, a conflict typically results in automatic denial to enforce a safety-conscious maintenance policy.

As shown in FIG. 5E, and by reference number 90, processors 48-1, 48-2 may independently determine to grant the service request. As shown by reference number 92, the processors may collectively determine to grant the service request based on a cross verification outcome whereby each processor 48-1, 48-2 independently determines to grant the service request. That is to say, the processors 48-1, 48-2 may compare their independently computed determinations to grant the service request and may collectively grant the service request after verifying that each processor 48-1, 48-2 came to the same decision. In this case, each processor 48-1, 48-2 may have an internal approval flag and may grant the service request by updating a state of the flag to a grant state to permit the service request to be provided to the crossing prediction device 32 and/or to the dispatch center server 38.

As shown by reference number 94, the processors 48-1, 48-2 may provide the service request to the crossing prediction device 32. The service request may include the original service request parameters (e.g., track segment identifier, requested duration, etc.), an indication that the jumper panel 30 has granted the service request following independent processor authentication, validation, and/or verification, and/or the like. The service request functions as a recommendation to grant the service request, subject to further validation and approval by downstream devices such as the crossing prediction device 32 and/or the dispatch center server 38.

In this way, the use of a cross-verification voting system implemented by processors 48-1, 48-2 of the jumper panel 30 improves operational safety by ensuring that multiple independent processor cores agree to grant a potentially hazardous maintenance request, thereby reducing the risk of single-point failures, undetected logic errors, or unauthorized service operations. This redundancy supports compliance with functional safety standards and helps maintain system integrity even in the presence of hardware or software faults.

As shown in FIG. 5F, and by reference number 96, the crossing prediction device 32 may validate the service request. For example, the crossing prediction device 32 may apply safety logic or a rules engine to evaluate the received service request, checking whether it is safe to grant the service request using current track status data, verifying that no rail vehicle is approaching or occupying the relevant segment, confirming predicted clearance windows, and confirming that no conflicts exist with other operational authorities. This validation step ensures that even a request approved by the jumper panel 30 is subjected to a second layer of independent safety analysis before being escalated to the dispatch center server 38.

As shown by reference number 98, the crossing prediction device 32 may provide the service request to the dispatch center server 38. For example, the crossing prediction device 32 may transmit the service request over a secure communication interface or network protocol, such as Genisys, Ethernet/IP, or cellular data link. The service request may include all relevant metadata such as the requested track segment, service request type data, timing parameters, authentication, validation, and/or verification results, status flags indicating approval by the jumper panel 30 and the crossing prediction device 32, and/or the like.

As shown by reference number 100, the dispatch center server 38 may approve the service request. For example, the dispatch center server 38 may analyze the service request using a human operator or a dispatch-side software system that analyzes the service request using centralized operational rules, network capacity constraints, and/or conflict resolution logic. As such, the system and methods described herein ensure that both the maintenance worker and dispatch personnel (and/or that the processors 48-1, 48-2 of the jumper panel 30 and the dispatch center server 38) agree on the intended track to be taken out of service. An approval message may then be generated which includes the approved track segment identifier, the approved time window, an authorization code, and any dispatch-imposed operational constraints or duration limits for the out-of-service period.

As shown by reference number 102, the dispatch center server 38 may provide the approval message to crossing prediction device 32. For example, the approval message may be transmitted over a secure communication link or network interface, as is described elsewhere herein.

As shown by reference number 104, the crossing prediction device 32 may provide, to the crossing controller 34, instructions indicating to disable the operation of the one or more components of the gate system 40. For example, the crossing prediction device 32 may use a wired or network-based communication interface to send instructions (e.g., which may be represented as command signals or control messages) that specify which crossing gates, lights, and/or warning bells to disable or to hold in a permissive state. These instructions may include parameters such as a track segment identifier, an authorized duration of disablement, a safety interlock condition, one or more command priority levels, and/or the like.

A safety interlock condition refers to a predefined logical or physical condition that must be satisfied to permit or sustain the disabling of one or more components of the gate system 40. For example, assume the crossing controller 34 receives instructions including a safety interlock condition, the crossing controller 34 may evaluate sensor data or relay states to confirm that the interlock condition is satisfied before executing the disablement command. The crossing controller 34 may refuse to disable components if the crossing controller 34 detects a train within a defined distance, if sensor health falls below a specified threshold, or if relay feedback states indicate that the relays controlling the gate system 40 are not in an expected safe or idle position (for example, if a relay is stuck in an active command state that would conflict with disabling or holding the gate in a permissive position). A command priority level refers to an attribute indicating the relative importance or urgency of a control command. The crossing controller 34 may compare command priority levels to determine which command to execute when multiple commands target the same hardware, selecting higher-priority command such as emergency stop instructions over lower-priority maintenance service requests.

As shown by reference number 106, the crossing controller 34 may use the instructions to disable operation of one or more components of the gate system 40. For example, the crossing controller 34 may de-energize actuator circuits to hold gate arms in the up position, inhibit activation of flashing light assemblies, suppress audible warning bells, and/or block control relay transitions that would otherwise enforce a fail-safe state. In some embodiments, the crossing controller 34 may disengage motor drives, maintain electrical hold-off voltages on solenoids, or open control circuits to prevent mechanical actuation of crossing warning devices. In some embodiments, the crossing controller 34 may set software or firmware flags that override or suppress normal activation logic linked to track occupancy sensors, maintaining the selected components in a permissive state for the duration of the authorized maintenance window.

As shown by reference number 108, the crossing prediction device 32 may provide a track status update message to the jumper panel 30. For example, the crossing prediction device 32 may provide a track status update message to the processors 48-1, 48-2 of the jumper panel 30. The track status update message may include data such as data indicating that the service request is granted, data indicating that the one or more components of the gate system 40 are currently out of service, data indicating the approved duration of the maintenance, data indicating any dispatch-imposed condition or constraint, status data of crossing controller commands, timestamp data for audit logging, and/or the like.

As shown by reference number 110, the jumper panel 30 may provide, for display on the user interface, an indication that the service request is approved and/or that the one or more components of the gate system 40 are disabled. For example, the user interface may display a green indicator light, a text message such as “Out of Service Granted,” an approved track segment identifier, a countdown timer for an authorized maintenance duration, or one or more other visual or audible cues confirming that the service request was successfully authorized and that one or more components of the gate system 40 have been disabled.

In some embodiments, the jumper panel 30 may further provide, for display on the user interface, a geographic representation of track segments indicating their current service status. For example, the user interface may visually depict which track segment is currently out-of-service (e.g., the track segment corresponding to the service request), which segments remain in service, and/or any pending service requests. In one embodiment, the user interface may be color coded (e.g., green for in service, red for out of service), may include text labels, and/or may include a schematic track layout that accurately reflects the physical or geographic crossing configuration. This geographic representation helps the maintenance worker immediately understand which tracks are affected, improves situational awareness during shift changes or safety briefings, and reduces the risk of human error by clearly distinguishing between safe and restricted operational zones.

In some embodiments, the maintenance worker may interact with the user interface of the jumper panel 30 to complete or close out a service request once a maintenance task has been finished. For example, the maintenance worker may confirm completion by selecting a “Complete” or “Restore” option on the user interface. The maintenance worker may also provide updated information for the service request log such as end time, work performed, or additional notes. Upon receiving this confirmation, the jumper panel 30 may transmit a service complete message to the crossing prediction device 32 and/or the dispatch center server 38, prompting the system to revert the operational state of the one or more affected gate system components back to normal operating conditions. One or more devices described herein may store this data as part of a log (e.g., a jumper log).

In some embodiments, the crossing controller 34 may automatically restore operation of the one or more components of the gate system 40 upon receiving an indication that a predefined timer associated with the service request has expired. For example, the processors 48-1, 48-2 of the jumper panel 30 and/or the crossing prediction device 32 may monitor the authorized maintenance duration and, upon expiration, cause a restore command to be provided to the crossing controller 34. The restore command may instruct the crossing controller 34 to re-enable normal warning signals, gate movements, and other safety devices even if no additional user-provided input is received from the local jumper panel 30. Additionally, or alternatively, authorized personnel at the dispatch center server 38 may remotely issue a command to the crossing prediction device 32 or directly to the jumper panel 30 to override the maintenance state and force restoration of normal operating conditions. These coordinated actions ensure that the one or more components of the gate system 40 are not left in a permissive or disabled state beyond the approved maintenance period, providing an added layer of safety and operational control.

In this way, the system described herein (e.g., the jumper panel 30, the crossing prediction device 32, the crossing controller 34, and/or the dispatch center server 38) improves operational safety, reduces the risk of human error during maintenance operation, and provides a robust, multi-layered framework for authorizing and coordinating service requests for railroad crossing gate systems. By integrating local redundant processing, predictive track status analysis, centralized dispatch oversight, and clear maintenance worker interfaces, the system enforces consistent safety rules, maintains auditability, and ensures that crossing equipment is only disabled when it is demonstrably safe to do so. Furthermore, while a conventional bypass jumper is a manually applied wire that directly overrides safety circuits, the jumper panel 30 and related system devices act as an integrated system to control and authorize maintenance bypass operations through processor-based authentication and verification, enforcement of safety criteria before granting the service request, and secure communication with the dispatch center server 38.

FIG. 6 is a diagram of an example interface of the jumper panel. The upper portion of the interface includes a touchscreen display showing a schematic map of the crossing labeled “CANAVERAL GROVES BLVD MP 157.40.” The schematic depicts two main track segments labeled T1 and T2, each represented by horizontal bars with boxes in the middle that display text such as 1 ISL and 2 ISL, indicating insulated joint or island circuit zones used to define detection sections for trains. Above and below these main tracks, white branching lines depict connections or track diverging routes, showing forked paths leading to labeled control points such as AGPK, AGDK, XRK, BGPK, BGDK, and buttons labeled SB1_AX_11K and SB2_AX_11K, which may represent specific signal locations, relay identifiers, or controlled devices in the field.

Below the touchscreen display, the lower portion of the panel contains physical toggle or rotary switches labeled T1 OOS, T2 OOS, T3 OOS, T4 OOS, T5 OOS, and T6 OOS, where “OOS” indicates “Out of Service.” These switches allow a maintainer to manually indicate or command that a specific track segment is being taken out of service for maintenance. The corresponding button above physical toggle may light up if the track segment is taken out of service. A “presence” indicator light is also provided, showing whether a key or authorization mechanism is engaged to enable operator control.

On the bottom right of the panel is a hardware section that includes two serial ports labeled SERIAL 1 and SERIAL 2 for RS-232 or similar serial communication connections. Next to these ports is a power light indicator that shows whether the unit is powered on, and a health indicator that represents overall system or self-diagnostic status. Adjacent to these are additional labeled light emitting diodes (LEDs) S1 through S4, which may serve as programmable status indicators for different internal states or diagnostic results. Finally, two ethernet ports labeled ETH 1 and ETH 2 are available for wired network connectivity to other systems, such as dispatch centers, crossing prediction devices, and the like. This user interface is provided by way of example, and in practice, modifications may be made to the user interface in accordance with the principles of the present disclosure.

Comparatively, most current systems use a single LED with an often abstract or incorrect text label to inform maintainers of which tracks are out of service. The jumper panel 30 enhances safety by eliminating accidental application of jumpers to wrong tracks. Further, the jumper panel may be implemented to provide clear geometrically accurate depictions of track layouts that visually react to maintainer “Out of Service” requests and current track status.

The foregoing disclosure provides illustration and description but is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. Modifications and variations may be made in light of the above disclosure or may be acquired from practice of the embodiments.

As used herein, the term “component” is intended to be broadly construed as hardware, firmware, or a combination of hardware and software.

Some embodiments are described herein in connection with thresholds. As used herein, satisfying a threshold may, depending on the context, refer to a value being greater than the threshold, more than the threshold, higher than the threshold, greater than or equal to the threshold, less than the threshold, fewer than the threshold, lower than the threshold, less than or equal to the threshold, equal to the threshold, etc., depending on the context.

Certain user interfaces have been described herein and/or shown in the figures. A user interface may include a graphical user interface, a non-graphical user interface, a text-based user interface, and/or the like. A user interface may provide information for display. In some embodiments, a user may interact with the information, such as by providing input via an input component of a device that provides the user interface for display. In some embodiments, a user interface may be configurable by a device and/or a user (e.g., a user may change the size of the user interface, information provided via the user interface, a position of information provided via the user interface, etc.). Additionally, or alternatively, a user interface may be pre-configured to a standard configuration, a specific configuration based on a type of device on which the user interface is displayed, and/or a set of configurations based on capabilities and/or specifications associated with a device on which the user interface is displayed.

It will be apparent that systems and/or methods described herein may be implemented in different forms of hardware, firmware, and/or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and/or methods is not limiting of the embodiments. Thus, the operation and behavior of the systems and/or methods are described herein without reference to specific software code-it being understood that software and hardware can be used to implement the systems and/or methods based on the description herein.

Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of various embodiments. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of various embodiments includes each dependent claim in combination with every other claim in the claim set.

No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Further, as used herein, the article “the” is intended to include one or more items referenced in connection with the article “the” and may be used interchangeably with “the one or more.” Furthermore, as used herein, the term “set” is intended to include one or more items (e.g., related items, unrelated items, a combination of related and unrelated items, and/or the like), and may be used interchangeably with “one or more.” Where only one item is intended, the phrase “only one” or similar language is used. Also, as used herein, the terms “has,” “have,” “having,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Also, as used herein, the term “or” is intended to be inclusive when used in a series and may be used interchangeably with “and/or,” unless explicitly stated otherwise (e.g., if used in combination with “either” or “only one of”).