RELATED APPLICATION AND CLAIM OF PRIORITY

This application claims priority to co-pending US Provisional Application No. 63/313,518 entitled Software for Railyard and Advanced Railroad Machine-to- Machine Interface filed on February 24, 2022 and having common inventor John Michael Minor.

TECHNICAL FIELD

The invention generally relates to railroad switch machines, and more specifically to signaling processing for mainline and in-yard railroad operation.

PROBLEM STATEMENT AND HISTORY

INTERPRETATION CONSIDERATIONS

This section describes technical field in detail and discusses problems encountered in the technical field. Therefore, statements in the section are not to be construed as prior art.

DISCUSSION OF HISTORY OF THE PROBLEM

Managing railroad yards and mainline rail is challenging. In years past, crewmen would walk the track and man the yards, throwing switches by hand while verifying track positions ... and a host of other functions. This process was and remains dangerous and time intensive. Additionally, as industry demands increased logistics efficiencies, tolerance for these inefficiencies is waning.

As a result, efforts have been made to automate switch yards and mainline railroad tracks. For example, a Flexyard® by 3Z Automation provides some limited switch automation features through independent components, and other similar devices are available from Ansaldo Energia®, Railcomm®, and Phoenix Contact® offer their own approaches. These approaches consume significant power, requiring external power sourcing, typically to AC power lines, while the ‘modularity’ of these systems makes any integration quite large and bulky. Additionally, none of the available devices offer an out-of-the-box solution for automating railroad switch control that is adaptable for real-time routing control, and flexible enough to integrate with a multitude of input/output devices, while simultaneously offering maintenance crews the ability to quickly diagnose and service performance issues in the field independent of their separate bulky test equipment.

Accordingly, there is the need for a railroad computing device and systems that overcome these and other limitations with the prior art. The present invention provides these and other advantages.

BRIEF DESCRIPTION OF THE DRAWINGS

Various aspects of the invention and its embodiment are better understood by referring to the following detailed description. To understand the invention, the detailed description should be read in conjunction with the drawings, in which:

Figure 1 illustrates an overview of a track switch schematic illustrating a deployment option for the invention;

Figure 2 illustrates a front-comer view of a first embodiment of a railroad computing device; and

Figure 3 illustrates a schematic of a power configuration for an embodiment of the invention;

Figure 4 shows a top-down view of the first embodiment of the railroad computing device;

Figure 5 shows a bottom-up view of the first embodiment of the railroad computing device;

Figure 6 provides an exposed-side view of the first embodiment of the railroad computing device;

Figure 7 illustrates a board-and-bus configuration for the railroad computing device;

Figure 8 illustrates web interfaces for displaying details regarding software, firmware, and programmed project information;

Figure 9 illustrates web interfaces for displaying details regarding software, firmware, and programmed project information;

Figure 10 illustrates web interfaces for displaying details regarding software, firmware, and programmed project information; and

Figure 11 illustrates web interfaces for displaying details regarding software, firmware, and programmed project information. DESCRIPTION OF AN EXEMPLARY PREFERRED EMBODIMENT

INTERPRETATION CONSIDERATIONS

While reading this section {Description of An Exemplary Preferred Embodiment, which describes the exemplary embodiment of the best mode of the invention, hereinafter referred to as “exemplary embodiment”), one should consider the exemplary embodiment as the best mode for practicing the invention during filing of the patent in accordance with the inventor’s belief. As a person with ordinary skills in the art may recognize substantially equivalent structures or substantially equivalent acts to achieve the same results in the same manner, or in a dissimilar manner, the exemplary embodiment should not be interpreted as limiting the invention to one embodiment.

The discussion of a species (or a specific item) invokes the genus (the class of items) to which the species belongs as well as related species in this genus. Similarly, the recitation of a genus invokes the species known in the art. Furthermore, as technology develops, numerous additional alternatives to achieve an aspect of the invention may arise. Such advances are incorporated within their respective genus and should be recognized as being functionally equivalent or structurally equivalent to the aspect shown or described.

A function or an act should be interpreted as incorporating all modes of performing the function or act, unless otherwise explicitly stated. For instance, sheet drying may be performed through dry or wet heat application, or by using microwaves. Therefore, the use of the word “paper drying” invokes “dry heating” or “wet heating” and all other modes of this word and similar words such as “pressure heating”.

Unless explicitly stated otherwise, conjunctive words (such as “or”, “and”, “including”, or “comprising”) should be interpreted in the inclusive and not the exclusive sense. As will be understood by those of the ordinary skill in the art, various structures and devices are depicted in the block diagram to not obscure the invention. In the following discussion, acts with similar names are performed in similar manners, unless otherwise stated.

The foregoing discussions and definitions are provided for clarification purposes and are not limiting. Words and phrases are to be accorded their ordinary, plain meaning, unless indicated otherwise.

DESCRIPTION OF THE DRAWINGS, A PREFERRED EMBODIMENT

INTRODUCTION

The invention provides a railroad computing device having a programmable processor capable of controlling any yard switch machine on the market, or any railroad device such as a single switch, wheel or track sensor, crossover, gates, bridges, crossings, derails and Blue Flag systems, for example. The processor can be programmed to execute any task compatible with its input banks or output banks, communication interfaces, wireless communication systems, and also consistent with processing capabilities as described below.

Operation modes provide generic inputs and outputs while the input and output functions are controllable and definable by a program installed in memory or operating remotely in communication with the reward computing device. A variety of pretested configurations for common applications are provided by custom programming available from Advanced Rail Systems® of Waco, TX.

DESCRIPTION OF THE FIGURES

Figure 1 illustrates an overview of a track switch schematic 100 illustrating a deployment option for the invention. The first track switch schematic includes a main route stock rail track comprising a first rail 110 and a second rail 111, a diverging route stock rail track comprising a third rail 112 and a fourth rail 113, a rail tongue 114, and a plurality of railroad related devices such as a switch machine 120, and track sensors 130, 132 and remote track sensor system 140. One exemplary switch machine is the ML18 switch machine 120 available from Advanced Rail Systems® of Waco, Texas, which is coupled to the tongue 114 the rods 122. The switch machine 120 includes a switch-point mover 124, and a railroad computing device 150 which is described in more detail below. The switch machine 120 may be coupled to a power and communications tower 160 via wire lines 126. The power and communications tower 160 generally comprises a base station 168, a when power source such as a Savonius wind generator 166 or a solar panel 167 shown elevated by pole 162. the poll 162 also supports cellular communication antenna 164 as well as a near field communications antenna 165. Although not illustrated, a satellite communications antenna may be provided to facilitate communications with a satellite 170, such as a Starlink® satellite.

Also shown in Figure 1 is a remote sensor system 140 which comprises an adjustable sensor 141, and a communications and power module 144. The communications and power module 144 being shown coupled to a solar panel 142 and a wireless antenna 146. although a solar panel is shown in Figure 1. It will be readily understood to those skilled in the relevant art that the solar panel could be interchanged with a another remote power device such as a windmill generator, and that the wireless antenna 146 is chosen to be compatible with a chosen wireless communication system including near field communications comprising Wi-Fi and Bluetooth, for example or remote communications comprising cellular or satellite communications, for example. A first layer of weather resiliency is provided to the railroad computing device 150 by the switch machine 120, while the railroad computing device 150 itself provides an additional layer of protection from elements such as fog, water, and corrosive chemicals, for example. Preferably, components and parts of the railroad computing device when 50 are chosen to provide operational resiliency in at least temperatures from -40 degrees Celsius to 85 degrees Celsius.

Figure 2 illustrates a front-comer view of a first embodiment of a railroad computing device 200. The railroad computing device 200 includes an aluminum housing 210, where the aluminum housing 210 comprises a housing front 250, a housing top 405, a housing bottom 505, a housing back 470 and exposed side 605, and an unexposed side 218. The aluminum housing 210 also has an interior that is discussed later. The housing front 250 has A screen 252, and a plurality of LED's, including a first LED 251 illustrating a power-on/off condition, a second LED 253, and third LED 255 (the second and third LEDs are auxiliary and program-definable LEDs). The screen 252 is preferably an Organic Light Emitting Diode (OLED), and is adapted to display a plurality of alphanumeric characters, the screen 252 is coupled to a userinterface board (discussed below).

The screen 252 is particularly useful for displaying information including: firmware and project information and versions, configuration parameters and communication addresses, active inputs and outputs for diagnostics, battery voltage, temperature, real time clock information, communications statuses, an internal counter, flag, alarm, or other performance indicator defined by an active project or software, as well as graphics that may aid a user in the field in diagnosing and troubleshooting a problem, or for interacting with any input or output related to the railroad computing device. Similarly, a Z1 (Zone 1) controller may show a number of wills in each zone, speed of movement, occupancy flags, and the like.

A user-interactive input device 256, shown here as a push-button and rotatable knob, is adapted to allow a user to scroll through an alphanumeric data displayed on the screen 252. As discussed below, the user-interactive input device 256 is coupled to a user-interface board. To facilitate user-interaction, also provided on the housing front 250 are user instructions 258. The input device 256 allows a user to navigate between panels and access information. And, when the input device 256 is pressed the display is activated and powers on. This allows standard configuration parameters to be adjusted in the field through the input device 256 and screen 252 rather than forcing the use of a computer interface device or web interface device in the field or at a remote location. In one embodiment, to exit the configuration menu, the user scrolls to the last option in the menu by rotating the input device 256, and selects return by pressing the input device 256 to resume normal operation, typically, this “return” option in the configuration menu manages this operation automatically and restarts the processor when necessary. While some configurations take place immediately after adjusting them, others require that the onboard processor be restarted to implement changes to the configurations.

Figure 3 illustrates a schematic 300 of a power configuration for an embodiment of the invention. The schematic shows a railroad computing device 310 having a bank of inputs 320 (shown here are inputs 1-16) and a bank of outputs 330 (shown here are outputs 116). A battery 340 is shown providing positive power channels to a first group of inputs and outputs, for example input channels 1 through 14, and output channels 1 through 14. The battery 340 also provides negative power channels to a second group of inputs and outputs, for example input channels 15 and 16 as well as output channels 15 and 16.

Preferably, positive inputs except voltages ranging between 9 volts DC up to 26 volts DC to be considered active. Negative inputs are active when connected to 0 volts DC, which is typically the batteries negative voltage. Positive outputs, when active can drive up to three amps with the same voltage from the external power supply’s voltage. Preferably, the first eight positive outputs include circuitry that allow the onboard processor to confirm the presence of a load when an output is active. The negative outputs can sync as much as two amps each. Preferably, all outputs include load monitoring capabilities and overload protection that will shunt the output down in the event of an overload or short circuit. When this happens, in one embodiment, the program running on the processor or remotely is informed of this failure for the first eight outputs. Output can resume normal operation automatically after the short circuit is solved.

Figure 4 shows a top-down view of the first embodiment of the railroad computing device, showing the housing top 405. From Figure 4 it can be seen that the housing top 405 comprises a bank of output connectors 420 that preferably has 16 outputs, a bank of power connectors 430, a bank of communication channel connectors 440, an RS-485 connector bank 450, memory slots including a slot for a Micro SD-Card 464, a slot for a mini-USB 462, a plug for coupling to a wireless communications wire 460, a microphone plug 410, and a hole 412 that leads to an internal board-mounted mic. The connection of the opponents shown in Figure 4 to their respective buses and boards internal to the housing are readily apparent to those of skill in the arts upon reading this disclosure. The bank of output connectors 420 includes connectors comprising at least a first output connector adapted to send a control signal to a first railroad device. Also illustrated in Figure 4 is the DIN-rail coupling 472 coupled to the housing back 470. The communication channel connectors 440 include an RS-232 connector.

Figure 5 shows a bottom-up view 500 of the first embodiment of the railroad computing device showing the housing bottom 505 in more detail. In Figure 5 is shown a bank of input connectors 510, preferably having 16 input connectors, a bank of communication inputs 520 including a speaker connector, a microphone connector, as well as a PTT an reference connector for a CANbus. Also provided is a CANbus bank of connectors 530 including connectors related to: CAN-L, CAN-H, a reference and shunts. Lastly, the housing bottom includes a wire line data communication receptacle 540 which is preferably an Ethernet connector. The Ethernet connector is preferably an Ethernet 10/100 IPv4 communication port.

Connectors on top and bottom of the housing facilitate installation when using DIN-rail installation. Most connectors are intentionally designed in different sizes to ensure they are not connected at the wrong position when replacing processors in the field. The functions of connectors is discussed in more detail following the discussion of Figure 7.

Figure 6 provides an exposed-side view 600 of the first embodiment of the railroad computing device. From the exposed side view 600 one can see that on the exposed side 605 is provided a computing device layout chart 610. Further, from this view, one can see that the DIN-rail coupling 472 is adapted to snap into a DIN -rail such that a channel is provided through which a communications bus and slash or a power bus can be run and allow multiple railroad computing devices to be couple slash daisy- chained together as described below.

Figure 7 illustrates a board-and-bus configuration 700 for the railroad computing device 200. The bus-and-board configuration 700 fit in the interior of the housing 210. A communications bus 710 couples a processor (or “cpu”) board 720 coupled to a digital signal processor 722 - such as a Cortex-M4® processor — and memory 724 for storing a unique device identification, to an input/output board 730. Further, the processor board 720 couples to a user-interface bus 740 which is in turn also coupled to a user- interface board 750. The screen 252 couples directly to the user-interface board 750. Similarly, the user-interactive input device 256 is coupled to the processor board 720. The bank of output connectors 420 and bank of input connectors 510 are coupled to the input/output board 740, and the wire-line data communications receptacle 540 is coupled to the processor 750.

One advantage of the inventive railroad computing device is that the devices can be daisy-chained together. In doing so, a second railroad computing device substantially similar to the railroad computing device discussed in the description of Figures 1 through 7 is communicatively coupled to one or more additional other railroad computing devices through their respective RS-232 Connectors.

Connections and Ports in More Detail

The input connections accept between 9 volts DC and 26 volts DC. Preferably, 7 of 16 inputs and four of 16 outputs can be configured to use OSD signals. Two out of 16 outputs and two out of 16 inputs are preferably negative types to facilitate interconnection with vital railroad track circuits (as this term is readily understood by those in the railroad arts. All inputs and outputs are surge protected to resist high voltages, and are implemented as connector pins known to those of skill in the railroad arts, such as those available from Wago(R).

Communication connections include RS-232 serial ports (spread spectrum, GPRS, and GSM compatible), and RS-485C cereal connectors. CANbus communication ports enable remote operation. Additionally, an input is provided for remote control using hand held the HF radios with Dual tone Multi -Frequency (DTMF) and voice messages. In one embodiment 32 messages of 20 seconds each are provided. Available communication protocols include ASP (Advanced Rail Systems Secure Protocol®), MQTT, Modbus TCP and RTU, as well as genesis.

In one embodiment, the railroad computing device 210 includes four serial ports: two CAN buses, an RS-232, and an RS-485C. The RS-232 can operate with different protocols as defined by the program or project that is running. Because the R- 232 can communicate with any source of RS-232 signals, It may handle communications via USB to RS-232 adapters, data radios, GPRS radios, and other RS232 ports for example, for the railroad computing device 210 RS232 port communicates with seven and eight bits, in one, odd and even parity, one stop bit, and in one embodiment operates from 300 bits per second up to 250 kilobits per second. This allows the RS-232 to enable the railroad computing device 210 to be Daisy chained as described below in Figure 6.

The available RS-485C port can operate using following parameters: 7and8bits, no parity, 1 stop bit, and preferably operates from 300 bps up to 130 kbps. Preferably, the network topology uses a bus with short leads, and preferably the bus is a twisted pair with 120 ohms of characteristic impedance. The bus terminators increase the stability of the system however are optional when this system runs at a low baud rate. The railroad computing platform 210 applies a bias and high termination to the bus line. This enables multiple devices to be installed between terminators. In the event the bus cable includes a shield (or is itself shielded cable) it can be connected to the reference signal provided at the RS-485C connector, in one embodiment the RS-485C connector communicate with one or more wheel counters and/or track sensors. In one embodiment as many as 21 will counters or track sensors are connected to a single railroad computing device and the logic that creates protection zones is handled in software. This enables sharing of each zones counting with other communication interfaces both local to the railroad devices as well as for remote monitoring.

The two CAN interfaces interconnect multiple railroad computing devices in a closed network. In this configuration the railroad computing devices share internal flags, registers, and signals to allow for the interaction of the railroad computing devices between projects to control each other. A crossover is a simple use case where two railroad computing devices are connected to allow two railroad switch machines to be controlled in synchronicity from a single point. Here, the topology is similar with that used by RS -485, with three differences: terminators must be used, shield connections must be used, and stubs should be as short as possible.

Each railroad computing device includes an internal Terminator that must be active by the installation of a jump at the CA N bus connector. Accordingly, a user can install jumps on units at the ends of a bus cable, or use an external terminator, such as a 120-ohm terminator. When using terminators two terminators must be used, one at each end of the bus cable. In a preferred embodiment, a properly terminated bus we'll have 60 ohms of resistance between its wires.

Daisy chaining railroad computing devices is protocol dependent. Specifically, when a data source, such as a data radio, is coupled to a railroad computing device’s RS-232 input, any other railroad device that is protocol compatible, may be connected to the RS-232 output to accomplish a Daisy chain output. To achieve a Daisy chain each device must have a unique network identification. With a Daisy chain setup a single data radio or other data source may communicate with multiple railroad computing devices. This reduces hardware costs and may reduce signal latencies while increasing communication reliability. In this configuration, Genisys functions include: OxFl - requested data response, 0xF2 - acknowledged acknowledge, OxFA - acknowledge received data, OxFB - Request modified index, OxFC - write index, OxFD - request full index, and Modbus RTU functions include: 0x03 - read multiple holding registers, and 0x04 - read multiple input registers.

The Ethernet port 540 parameters may be adjusted by software or through a web interface. For security reasons the Ethernet port does not work with DHCP or any other automatic configuration protocol. Accordingly, a user must manually set the parameters for the port to properly work, including unit IP, MAC (optional), sub-net mask, Gateway IP, DNS IP, and optional SNTP IP. A user may also set other parameters, including: enable internal HTTP server for remote configuration, set TCP/UDP port for modbus/TCP protocol, set UDP port for Genisys protocol, and set UDP port and keys for ASP protocol. However, it is preferred that only one protocol is selected for each application. HTTP protocol is active at the same time via port standard 80 thus allowing users to connect to the railroad computing device using a standard web browser to configure it and check the event log. In the event a HTTP server rather than a secure HTTPS server is used, it is important to be aware of and manage security issues related to operation.

The railroad computing device includes an interface to a V HF radio that provides use of a standard handheld radio to send DTMF commands for processing 2 the device, and to receive response messages that are triggered by a running software application. This provides for the safe operation of equipment outside of an operators view, does so with multiple commands, while receiving audible messages to confirm the command was properly executed and when it is not properly executed, the reason the command failed. In one embodiment a software application can define up to 32 DPMP commands and playback 32 voice messages. A user can change DTMF codes using a web interface, or through the push button knob. To execute a change using the user interface, the user: (1) enters the configuration menu, (2) rotates the knob to locate the DTMF code that needs to be changed, (3) ‘clicks ’/selects the code to activate it, (4) types the new DTMF on a handheld radio, (5) checks the screen to verify that the code is correct (if is it not correct, the user may pause for two seconds and try again), and (6) if the new code is correct, clicks to activate the operation menu and move to the Desired option choice (see below), and (7) rotates the knob to locate the “Return” selection, and clicks/ selects it to leave the configuration menu and resume normal operation. Desired option choices include: EDT (Edit) to resume editing the code, SAV (Save) to save the new code and leave, and EXT (Exit) to leave without saving.

A local user interface allows a user to set parameters directly in the railroad computing device’s screen. However, for more specific settings, project/ firmware upgrade or event log access, a user must use an embedded web interface via a laptop remotely using a connected network. Specific operation and setting are software and application specific.

Adjustments Via Web Interface

Simultaneous reference is now made to Figures 8-11, which illustrate web interfaces for displaying details regarding software, firmware, and one or more programmed project(s) information. The first page of the web interface details information about current unit installed firmware and installed project for reference as shown in Figure 8. Similarly, Figure 9 more particularly illustrates a web interface’s Events tab. The Events tab view displays the current unit’s events, presents them in a table, and provides for exporting them in a CSV format that can be opened by a spreadsheet such as Excel®. The railroad computing system’s clock may be matched to the clock of the laptop using the web interface (although the clock syncing should be accomplished automatically). In operation most Events are defined on a project-by- project basis. Only a few events like, power on and off, upgrades, or clock syncing are managed by the railroad computing device itself.

The Config tab (Figure 10) reads current configurations and allows adjustments to be made. There are preferably two columns of configuration parameters, the left column is defined by the currently installed project software. In this case a project’s datasheet provides DTMF codes, DTMF voice messages, and any other configuration adjustment that determines project operation. The right column presents system configurations. These are defined by the current version of firmware. Current values are preserved in-between upgrades as long the new project being installed is using the same firmware. System configuration allows a user to set a railroad processing device’s communication parameters like IP, TCP/UDP ports, units IDs, port speeds, and active protocol, for example.

For updates and upgrades, see Figure 11. Tab Upgrade allow to install a new firmware and/or application to this unit. Applications are created with a custom language named ARMMILL® (Advanced Rail Man Machine Interface Logic Language®). Once compiled, they are distributed in a file with extension “armmiproject”. These files are named with a standard format that provide project name, description, version and current firmware installed with it. As an example:

STD-R-S W-P008-Remote_switch_with_aimcan. V22_l 25. armmiproj ect

This translates as: Application reference STD-R-SW, version POOS, description: Remote_switch_with_aimcan and firmware V22_125 is packed inside this same file.

Once the armmiproject file is loaded, this tab-view of the web interface shows data from what is currently installed on a connected unit and the data from a loaded file. Some, applications may have a minimum firmware version requirement. When currently installed firmware does not satisfy a requirement, a new firmware will be installed by default. The end-user, presumably a customer, selects whether or not to upgrade firmware (here, by selecting the switch to the right). When writing an application, a developer can optionally create texts in multiple languages to be able to use a single application in different countries. When the loaded application has multiple languages available, a selection box allows the desired language to be selected before upgrade execution. Although the invention has been described and illustrated with specific illustrative embodiments, it is not intended that the invention be limited to those illustrative embodiments. Those skilled in the art will recognize that variations and modifications can be made without departing from the spirit of the invention. Therefore, it is intended to include within the invention, all such variations and departures that fall within the scope of the appended claims and equivalents thereof.