Source: http://www.google.com/patents/US6400281?dq=5,371,548
Timestamp: 2014-10-22 15:34:09
Document Index: 429086405

Matched Legal Cases: ['Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60']

Patent US6400281 - Communications system and method for interconnected networks having a linear ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA system and method for communicating over networks, particularly generally-linear networks such as a netowrk of railcars in a railway train. The disclosed system and method include the relaying of packets which may contain plural messages down a line of nodes. Acknowledgement of the packets is obtained...http://www.google.com/patents/US6400281?utm_source=gb-gplus-sharePatent US6400281 - Communications system and method for interconnected networks having a linear topology, especially railwaysAdvanced Patent SearchPublication numberUS6400281 B1Publication typeGrantApplication numberUS 09/042,722Publication dateJun 4, 2002Filing dateMar 17, 1998Priority dateMar 17, 1997Fee statusPaidAlso published asCA2283695A1, CA2283695C, DE69839628D1, EP1008254A2, EP1008254A4, EP1008254B1, US6867708, US20020027495, WO1998042096A2, WO1998042096A3Publication number042722, 09042722, US 6400281 B1, US 6400281B1, US-B1-6400281, US6400281 B1, US6400281B1InventorsAlbert Donald Darby, Jr., David Peltz, Mark Hefner, Irfan Ali, William Schoonmaker, George JarmanOriginal AssigneeAlbert Donald Darby, Jr., David Peltz, Mark Hefner, Irfan Ali, William Schoonmaker, George JarmanExport CitationBiBTeX, EndNote, RefManPatent Citations (34), Referenced by (56), Classifications (60), Legal Events (7) External Links: USPTO, USPTO Assignment, EspacenetCommunications system and method for interconnected networks having a linear topology, especially railwaysUS 6400281 B1Abstract A system and method for communicating over networks, particularly generally-linear networks such as a netowrk of railcars in a railway train. The disclosed system and method include the relaying of packets which may contain plural messages down a line of nodes. Acknowledgement of the packets is obtained implicitly by listening to a subsequenct relay of the packet and retransmission of the packet is effected on a diverse antenna in the event of non-acknowledgement. Message bandwidth is shared among the nodes of the system by a message priority system and by the reservation of portions of a packet for certain types of messages. Message bandwidth is also shared by the use of groups of nodes as relay particpiants and by periodically changing the group which is peforming the relay operations.
What is claimed is: 1. A communication system of operational transceivers comprising:
plural, operational mobile transceivers, spaced from one another; means for sending messages from a first of said transceivers to a second of said transceivers wherein each message is relayed by one or more but not by all operational transceivers located generally between said first transceiver and said second transceiver at the time of message transmission; each relay of a message confirming safe receipt of the message; means for selecting which of said transceivers relay messages is generally cyclical so that all transceivers between said first transceiver and said second transceiver periodically receive and relay messages; and plural spatially diverse antennae at each transceiver, a transceiver relaying a message on a first one of said plural antennae sending the message on a second one of said plural antennae in the absence of timely acknowledgment of the message sent on the first one of said plural antennae. 2. The communication system of claim 1 wherein a transceiver relaying a message to another transceiver resends the message to a third transceiver in the absence of a timely acknowledgement of the message sent to said another tranceiver.
3. A communication system for a linear network of operational nodes comprising a pilot node, an ending node and plural operational intermediate nodes, said operational intermediate nodes being generally located between said pilot node and said ending node, said communication system comprising:
a transceiver at each node; means for periodically initiating a message at said pilot node; means for relaying said initiated message from said pilot node to said ending node, the relaying being accomplished by some but not all of said operational intermediate nodes; and plural diverse antennas at each node, the message being resent by the relay node on a different antenna than used to receive said message if the relay node cannot determine that the message has been received by the designated node. 4. A communication system for a linear network of operational nodes comprising a pilot node, an ending node and plural operational intermediate nodes, said operational intermediate nodes being generally located between said pilot node and said ending node, said communication system comprising:
a transceiver at each node; means for periodically initiating a message at said pilot node; means for relaying said initiated message from said pilot node to said ending node, the relaying being accomplished by some but not all of said operational intermediate nodes and said message being resent if the first sending of said message is not received within a predetermined time period. 5. The communication system of claim 4 wherein a relaying node considers said message to be acknowledged when the relaying node hears a subsequent relay of said message.
6. The communication system of claim 5 wherein said ending node relays said message to itself.
7. The communication system of claim 5 wherein said pilot node relays said message to itself.
RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Application No. 60/040,585, filed Mar. 17, 1997, U.S. Provisional Application No. 60/040,586, filed Mar. 17, 1997, U.S. Provisional Application No. 60/044,333, filed Mar. 27, 1997, U.S. Provisional Application No. 60/043,753, filed Apr. 9, 1997, U.S. Provisional Application No. 60/064,529 filed Nov. 5, 1997, and U.S. Provisional Application No. 60/066,304, filed Nov. 25, 1997
BACKGROUND OF THE INVENTION The present application is related generally to systems and methods for communicating with nodes in a linear network and in particular to a system and method for communicating among and controlling rail vehicles.
Over the last couple of decades, and particularly recently, electronic improvements to railway braking and control systems have been introduced. For example, communications have been established between plural locomotives, remote from each other, in a train so that a single operator can control the throttle and brakes of locomotives spaced throughout a train. This system, known as the LOCOTROL� system, utilizes a radio frequency link between a lead locomotive and one or more trailing locomotives to control the throttle and braking at the various locomotives. The LOCOTROL system provides both for a more even pulling of the railcars and for an improved braking performance because each locomotive can effect the braking signals using the speed of the RF communications rather than the slower speed of the pneumatic brake pipe signal. For another example of the improvements already obtained by the use of electronics in the railway locomotives, in one electronic system, the pneumatic braking valves at the locomotive which control the brake pipe have been replaced by electronic sensors and actuators which provide for more reliable control of the brake pipe signals. In another change, braking systems have been proposed in which the brakes at each railcar are electronically operated in response to electrical signals carried by an electrical wire which passes through and between each railcar in a train. While a wired braking system provides the benefit of braking signal propagation at the speed of light, the wires which carry the braking signals from car to car are subjected to a harsh environment and may be susceptible to damage. Worse, a break or disconnection in the wire controlling the train will result in an undesired emergency braking of the train.
BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a simplified pictorial diagram of a train system in which the present invention may be utilized.
DESCRIPTION OF PREFERRED EMBODIMENTS The present invention is described herein with particular reference to a railway system. Although one embodiment of the present invention finds considerable usefulness in such systems, it is not limited thereto and, as will be appreciated to those skilled in the art, is applicable to other communication systems, especially those used in networks wherein the various nodes are not generally within a circular cluster.
With reference now to FIG. 1, the present invention may be used in a train 10, comprising a Head End Unit (�HEU�) 12, plural Rail Car Units (�RCU�) 14, and one or more Distributed Power Units (�DPU�) 16. The HEU may communicate with one or more of the RCUs through a radio link through antennas 18 associated with the HEU and with each of the RCUs with which communication is to be established. Similarly, the HEU 12 may communicate with each of the DPUs 16 and any other similar assets on the train through the antennas 18. As detailed below, the RCUs 14 may likewise communicate with the HEU 12, the DPU 16 and with other RCUs within the train 10. Throughout this description, the terms �radio link�, �RF communications� and similar terms are used to describe a method of communicating between two links in a network system. It should be understood that the linkage between nodes in a system in accordance with the present invention is not limited to radio or RF systems or the like and is meant to cover all means by which messages may be delivered from one node to another or to plural others, including without limitation, magnetic systems, acoustic systems, and optical systems. Likewise, the system of the present invention is described in connection with an embodiment in which radio (RP) links are used between nodes and in which the various components are compatible with such links; however, this description of the presently preferred embodiment is not intended to limit the invention to that particular embodiment.
With continued reference to FIG. 1, the HEU 12 may also communicate via a radio link with a Network Management site 20. Likewise, the Network management site 20 may communicate via a radio link with various Wayside Units (�WU�) 22 which are associated with the track on which the train 10 is to be run. The WUs control and/or communicate with various track resources, such as switches, train presence detectors, broken rail detectors, hot box detectors, signals, etc. conventionally used in railway systems. A WU may be a part of and control a single device, such as a switch, or may be a control processor which communicates with and controls several devices (generally located near each other) such as a switch, train detectors on the track segments associated with the switch and signal apparatus associated with the switch. A further and exemplary description of the structure and operation of such devices may be in U.S. patent No. 6,135,396 issued on Oct. 24, 2000 entitled �System and Method for Automatic Train Operation� and assigned to the assignee hereof.
In operation, the radio links of the RCUs, the HEU, the DPUs, the WUs and the Network Management site may be operatively connected in a conventional fashion to transceivers (not shown), decoders (not shown) and to control processors (not shown). As is well known, the control processors may control one or more devices associated with the HEU or the RCUs. For example, the control processor on the RCU may control the application of brakes by the RCU. Similarly, the RCUs, WUs, DPUs and the HEU may include remote monitoring/measuring devices which report various conditions to the control processor, which can in turn be reported through the radio link to other elements. For example, one or more of the RCUs may include a meter to measure the air pressure in the brake pipe of a air brake system. In an exemplary system, the pressure within the brake pipe at a particular RCU may be measured by such a meter, reported to the control processor, and communicated to the HEU or other RCUs.
With reference now to FIG. 2 where like elements are provided with the same reference numeral as in FIG. 1, communications within a train 10 carrying out one embodiment of the present invention generally require a flow of messages to and from the various vehicles of the train. For example, train control at steady state will usually require a regular (repeated, periodic) communication from the HEU to all RCUs (�Status Poll�). Similarly, the communication should accommodate regular (repeated, periodic) checks of the brake supply pipe pressure at the end of the train (assuming that the bakes are pneumatic). The HEU should be able to direct communications to individual cars (�DP Command�), or alternatively, to all of the cars at once (�Brake Command�). The HEU should also be able to obtain information regarding the status (function, health, conditions, etc.) regarding all applications running on all of the cars. The HEU should be able to receive status messages from the RCUs (�Poll Response�) and from the End-Of-Train RCU (�Supply Pipe Status�). Finally, the HEU should be able to receive unsolicited messages from all of the RCUs. These unsolicited messages may be asynchronous to the normal message timing and generally convey unexpected events, such as a sudden loss of supply pipe pressure.
With reference to FIG. 3, the messaging requirements of a communications system in accordance with the present invention may be carried out by a car control device (�CCD�) 30 in which power is supplied by a battery 32, which may be recharged by a wheel-mounted generator 34 through a voltage regulator 36. The power may be supplied to the various electronic elements of the CCD 30, including an IntraTrain Communications (�ITC�) engine 38, a valve interface 40. The ITC engine is a processor which controls the communications between the car and the HEU through a transceiver consisting of a transmit function 42 and a receive function 44 which may receive radio signals from or provide radio signals to diverse antennas 46, 48 through an antenna switch 50 and a transmit/receive (�T/R�) switch 52. The ITC engine 38 also controls the communication to other devices on-board the car through a subnet devices controller 56 which is connected to various subnet devices, 56, 58, such as sensors, application communications modules, environmental controls, etc. The ITC engine 38 also controls the operation of the brake valve interface 40 which, in turn, controls a brake valve and the associated brake cylinder 62, auxiliary and emergency reservoirs 64 and a port to the brake pipe 66.
Any number of communications protocols could be used, with varying degrees of success, to pass messages from one car of a train to another. The selected protocol must be able to pass messages reliably within a train, be relatively free of interference from similar communications on other trains or from intruders, communicate messages within the time latency requirements for the systems being controlled (e.g., braking systems), and be able to handle different types of messages from different types of rail vehicles, all within an environment which changes as the train moves along the track and which may be filled with adverse environmental factors. Moreover, the selected protocol must address the inevitable equipment failure of various system components and be able to continue operation despite the absence of one or more nodes within the communications system. In one embodiment, the system and method of the present invention includes a communications protocol which satisfies these and many other constraints faced by a communications protocol on a moving train. With reference to FIG. 4, each of the rail vehicles of a train can be considered a node of a communications network. In the protocol used in this embodiment, one of the nodes is considered a pilot node and one of the nodes is considered a reversing node. Usually, the pilot node will be at the locomotive and the reversing node will be at the last functioning car in the train (the �End-of-Train� car). Each node is given a logical address corresponding to its position within the train (NODE 1, NODE 2 . . . NODE 9) starting with the pilot node, Each car in the network is also assigned (usually during linking) to a relay group, with the pilot node and the reversing node being assigned to all groups.
As the packet is relayed down the train, each node which receives the packet decodes the packet and operates on its contents, if appropriate. Thus, in the example train of FIG. 4, NODEs 2, 4, 6, and 8 are not explicitly addressed by the relayed packets but are highly likely to be able to receive the packets. When the packet is received and decoded, each of the non-addressed nodes reviews the message(s) contained in the packets and acts responsively. For example, if the message is a brake command addressed to all nodes, each of the receiving nodes operates its brakes in accordance with the message, even though the packet was not explicitly addressed to it. On the other hand, if the decoded message is a status query to the reversing node (NODE 9), all of intermediate nodes will disregard this message.
To ensure reliable communications, each node seeks confirmation that each packet that its sends has been successfully received by the relaying node. In a conventional communications system, such a confirmation could be received by an explicit acknowledgment message provided by the receiving node; however, such acknowledgments consume considerable bandwidth of the communication medium and are not generally used in this aspect of the present invention. Rather, when a node in the present invention relays a packet, it records the hop count of the packet and schedules a time to retransmit the packet. If the relaying node �hears� the packet being further relayed (by the relay recipient) before the retransmit timer expires, the relaying node knows that the packet was received correctly and cancels the retransmission. Note that the relaying node does not require that it hear the relayed (acknowledging) packet error-free. If the acknowledging packet has a valid train ID and hop count, the relaying node can consider the packet to have been received. The acknowledged node can assume that the node sending the transmission received it error free or it would not have forwarded it. If, on the other hand, the original node does not hear the implicit acknowledge within a predictable time period, it can assume that the destination node did not receive the packet error free, and thus did not relay it.
The reversing node has additional responsibilities than the intermediate nodes. Since there are no further nodes in the network, another relay is not needed to continue the packet toward the end of the train. However, unless the last relaying node is notified that the reversing node has received the packet, that relaying node will retransmit the packet. To prevent these unneeded transmission, the reversing node will transmit a �stopper� packet which can be a short packet serving as an explicit acknowledgment that the last relayed packet has been received. The stopper packet may be a short packet which the reversing node addresses to itself, thus eliminating any further expectations of retransmission. In addition, the reversing node also serves to initiate an in-bound (moving toward to pilot node) packet. The inbound packet may contain a repeat of any messages from the outbound packet which were marked for �rebound�, messages from any applications operating at the reversing node, responses from the reversing node itself (brake pipe pressure, for example). The inbound packet is addressed to be carried by the same relay group that carried the messages on the outbound journey; the flag in the packet is set to designate that it is an inbound packet, the hop count is incremented and the packet is transmitted by the reversing node. The inbound packet sent by the reversing node will be sent for relay by the first node in the reverse relay group (this node may be, but is not necessarily, the same as the last node in the outbound relay group). With reference to FIG. 4, the reversing node sends the packet to the first Group II node on the reverse path, i.e., to NODE 7. The packet is thereafter relayed by each of the relay nodes in the same manner as was the outbound packet, described above. Similarly as for outbound packets, each relaying node sets a retransmission timer which will cause a retransmission of the packet if the node does not �hear� the further retransmission of the packet by the next relay node. When the packet arrives at the pilot node, the pilot node sends a stopper packet to expressly acknowledge receipt of the packet and to turn off the last relaying node's retransmission timer.
In operation, the pilot node uses the above-described protocol to command the various nodes and to obtain the status of any of the nodes. Each packet sent by the pilot node may contain a brake signal. The packet may also contain messages polling for the status of any of the nodes or of any application running on any of the nodes. Additionally, the packet may contain throttle commands or other engine related commands (tractive effort, use of sand, etc.) for distributed power units (which may access the train's communications network like any other rail vehicle). When the ITC engine within a node receives a packet and determines that the sequence number has not been seen recently (explained further below), the ITC engine may make copies of each message within the packet applicable for each of the applications running on the node and provide the copies to the appropriate applications. The applications may process these messages and generate reply messages, either responsively or on an ad hoc basis. These messages may be appended to the next inbound packet that the node is asked to relay, subject to a maximum packet length. When the messages from the applications are received at the pilot node, the pilot node will distribute each of the application messages to its applications, thus completing the message cycling needed to maintain a complete status of the train.
With continued reference to FIG. 5, the pilot node (Node 0) initiates the packet by generating the packet to include three messages: a status poll command for Node 3 (�STATUS POLL� in the message outline, a brake command (�BRAKE CMD�) for all nodes and a command to a distributed power unit at Node 5 (�DP COMMAND�). At about the same time, Mode 7 detects an alarm condition and generates an unsolicited message to be sent to the pilot node. Because the last outbound packet was sent through the first group of relay nodes, the pilot node addresses this message to be relayed by the second group of relay nodes (the �odd numbered� nodes) and addresses the packet appropriately in the header (�HDR�) and sets the hop count to one. The packet is then transmitted by the pilot node which also schedules a retransmission in case an acknowledgment is not received.
The sequence of events is repeated at each of the nodes receiving the packet until the packet reaches the reversing node (Node 10). As with all messages, the reversing node ensures that the packet was sent by a node on its train and that it has a sequence number not recently seen. The reversing node, accordingly, sends a stopper packet to cause Node 9 to cancel its retransmission. In addition, the reversing node formats a packet for an inbound journey. The inbound packet is similar to the outbound packet, changing the direction flag to inbound. Each message which has been tagged by the pilot node for �rebound� is included in the inbound message. (In the example system of FIG. 5, the status poll, brake command, and distributed power command were designated for rebound) Rebound of the message increases the probability that all nodes, even those not included in the current relay group, receive the message. The reversing node appends a message providing the pilot node with the status of the brake supply pipe (�SP ST.�). The reversing node sets as the relay node in the packet the operative node in the second group, i.e., Node 9, updates the remaining header fields and retransmits the packet on the same antenna on which it was received.
Each of the nodes on the inbound packets process the packets in a fashion similar to that used for the outbound packets, ensuring that the packet was received from a node on its train, distributing application messages not previously distributed, and relaying the message back to the pilot node. However, for inbound packets, each of the relaying nodes has an opportunity to append a message which its wants to send to the pilot node. In the example of FIG. 5, Node 7 will add an unsolicited message (�UNSOLIC.�) notifying the pilot node of a sensed alarm condition. Likewise, Node 3 will append its Poll Response message (�POLL RESPONSE�) to the inbound packet. The ability of the relay nodes to add messages to the inbound packets may be limited by priority and bandwidth considerations as explained further below.
In an alternative embodiment, rather than use the group relay scheme designated by a pilot node, the nodes in one embodiment of the present invention may determine for themselves the distance which messages can be reliably transmitted and select as the primary target the node at that distance. For example, the relaying node could attempt to relay a packet ten nodes ahead. Nodes in between the relaying node and the destination node can await to see if the destination node acknowledges the message. If the message is acknowledged, the intermediate nodes need inquire no further (attending to their duties of distributing messages to their hosted applications). If the message is not acknowledged, the intermediate nodes can in turn acknowledge the message (starting with the node next before the destination node). Note that if another node has already acknowledged the message, a relay node will not acknowledge the message. By keeping track of which node acknowledges its packets, a particular relay node can dynamically determine the node to which can be sent reliably. Because the RF environment associated with a moving train changes, the relay node may periodically attempt to push the relayed packet out further and analyze the results. Similarly, if the packets being relayed by a particular node are regularly being acknowledged by a closer node, the particular node can update its routing table to relay ist packets to the closer node. In this way, the nodes attempt to forward the packet as far as reliably obtainable, reducing the number of hops (and time) needed for a packet to traverse the entire train.
In its simplest form, as explained above, the retransmission system which may be used in the present invention includes a timer which causes a node to retransmit a packet if an acknowledgment of the packet is not received within a predetermined period of time. When the retransmission timer expires, the node may resend the packet, this time on the other antenna from that used the first time. In this way, if one of the antennas are inoperative or if the RF propagation conditions on one side of the railcar are less than ideal, the use of the other antenna helps to ensure packet delivery. Again, upon the retransmission of the packet, the relaying node sets its retransmission timer and, if an acknowledgment message is not received before the timer expires, the relaying node retransmits the packet to a new destination node. During setup of the network, each node is provided with a logical address (as discussed above) and with an identification of three forward (outbound) target nodes and three reverse (inbound) target nodes. The first target node will generally be the next node (inbound and outbound) in the relay group in which the node is assigned. This node may be called the Primary Target. The second set of target nodes, called the Secondary Target, are generally nodes which are closer to the relaying node but are not necessarily in the same relay group as the relaying node. Finally, the third set of target nodes, called the Fallback Target, will be a set of nodes close to (generally next to) the relaying node. Thus, the Fallback Target generally represents the node to which communications may most likely be successful. In operation, the relaying node first tries to relay a packet to the Primary Target, using first the �preferred� antenna (usually the antenna on which the packet was received) and then of the �alternate� antenna. If the transmission is not acknowledged, the relaying node attempts to retransmit the packet to the Secondary Target, first on the preferred antenna and then, if needed, on the alternate antenna. Finally, if the transmission still has not been acknowledged, the relaying node attempts to resend the packet to the Fallback Target, first on the preferred antenna and then on the alternate antenna.
The routing tables may contain the Primary, Secondary and Fallback Targets for each relaying node for each relay group established by the network manager. The targets are specified by the network manager to maintain the packets within the assigned relay groups to the extent practical and to return a packet which has been relayed outside of its assigned relay group back to its assigned relay group. Thus, if a relaying node is part of a particular group, its Primary Target within that group will generally be the next destination address within the group. If the node is not a member of the group, the Primary Target will generally be set to return the packet to the normal members of the group. For example, in a two group relay setup in which all the even numbered nodes are in group A and all the odd numbered nodes are in group B, if a packet designated for Group A is set to be relayed by Node 4, the routing table of Node 4 would likely be set to Node 6 (the next destination within Group A). If a packet designated for Group B is set to be relayed by Node 4 ( a Group A node), the routing table for Group B at Node 4 would specify a Primary Target within Group B (nodes 5, 7, 9 etc., depending upon how aggressive a routing sequence has been set). Thus, if a Group A packet arrives at a Group A node (Node 4, for example), the node's routing table will attempt to keep the packet for relaying within Group A. If a Group B message is received by a Group A node, the routing table for the node will attempt to return the packet to Group B by setting a Group B node as the Primary Target.
In one aspect of the present invention, messages may be allocated different levels of priority. Regular priority messages may contain non-critical information such as the status of non-vital systems, unsolicited responses containing non-critical status, routine polling messages, etc. These messages have the lowest priority available and in normal operations will likely be the most numerous in a train. �Brake� priority messages have the highest priority of the normal messages since the train's brakes are the safety critical system on the train. Brake messages include normal status polls and responses from the brakes, as well as unsolicited brake messages. �High� priority messages may be used for critical information, safe as safety critical unsolicited responses from on-car systems, etc. A fourth priority message, Severe priority, may be used for messages that must get through the system with a minimum of latency.
If implemented, a Severe priority message causes the node to reverse an outbound packet. Generally, only one Severe message can be appended to the packet and no lower priority messages can be appended. Severe priority messages may also be sent outbound, and such messages cannot be reversed by a pending inbound Severe priority message. Thus, the pilot node can send critical messages using a Severe message priority and be confident that the packet will not be circumvented in its outbound trip. (As used herein, a Severe Message Token (or packet) may be called a �SMOKEN�).
The foregoing has described a network in which packets are relayed synchronously from the front to the rear and than back to the front of a train. There are instances when such synchronous communications may not be sufficient or desirable and the present invention includes the capability to send asynchronous packets (where asynchronous designates that the packet is not sent as part of the �norma� packet forwarding and reversing of the network). Such asynchronous packets may be sent, for example, when the network is being linked, when a linked node believes itself to have become unlinked, or when a node desires to transmit a packet immediately and not await a synchronous packet in which it can append its message.
Asynchronous packets may also be sent by nodes in response to host applications which request that a message be sent by an asynchronous packet. In such a circumstance, the node need not await an inbound packet onto which it can append a message but may transmit the message asynchronously. As described above, nodes receiving the network to relay the message to the pilot node. The structure of the asynchronous packet is similar to that of a synchronous packet; however, many of the fields have no significance and are not used (Hop Count, Sequence Count, etc.)
Those skilled in the art will appreciate that the communication system of the present invention could be implemented with a variety of packet and message structures. However, the inventors hereof have found that the packet and message structure described below to be particularly advantageous in carrying out the objects of the present invention. As described repeatedly above, the system of the present invention may be used to carry messages between the nodes of the network. Each packet may contain several messages, each message concerned with one or more application(s) at the receiving node(s). Data may be transferred in the form of data packets, the most fundamental data packet being termed an Application Data Unit (�ADU�). In one embodiment of the present invention, the ADUs may have a fixed structure contained overhead information and up to 64 bytes of free form application data. Special ADUs may be used for downloading code to the nodes in which up to 255 bytes of application data are permitted. With reference to FIG. 7, an ADU may have a format in which certain bits as indicated in FIG. 7 are used to signify various functions or data. The Write Over Flag specifies whether the ADU can be written over by the ITC engine. Messages received by the ITC engine from the applications on a particular node are queued by the ITC engine until they can be placed in an available packet. While such messages are awaiting transmission, the data contained in the message may become stale or invalid. Applications may replace their messages on the transmit queue until just prior to their transmission. A new message will �write over� an old message; however, the new message retains the old messages position within the transmit queue. Messages that are intended to update queued ADUs have the Write Over Flag set.
The Source Application ID is set to a value to match a standard set of IDs. Application IDs are used to identify ADU sources and destinations, and are generally assigned to a functional entity (such as a brake control function on a car control device or the network management function on a node). Generally, the originating ADU adds its own application ID to the ADU to give the destination a return address (when combined with the ADU's Source Address). Any message sent in response to a received ADU should be addressed to the requesting application. In an alternative embodiment, the application IDs could be allocated to the applications by the network management scheme, particularly during setup of the train.
In a preferred embodiment of a system of the present invention, information may be passed between nodes in the form of Radio Data Units (�RDUs�). RDUs contain overhead information which is used by the communication system and up to sixty four Application Data Units (ADUs), such as described above. With reference now to FIG. 8, the Circuit Identification Code identifies a unique communication circuit which is transferring the RDU. Within a communication system, there may be plural circuits identified. For example, in a preferred embodiment of the present invention, three circuits may be used: a Service Circuit, A Train Link Circuit and a Maintenance Circuit. The service Circuit may be the default for all nodes on the network. Any packet received and marked with a Service Circuit ID will be received by a node. The service circuit is the circuit used to link nodes into the network and is generally the only way to communicate with a node which has not been linked into the network. The Service Circuit may also be used as a maintenance interface to a linked node (or alternatively, a Maintenance Circuit may be implemented in a network and used for the maintenance interface or for status monitoring by equipment not directly linked to the train's synchronous network, such as wayside equipment). The Train Link Circuit identifies a train network in a linked mode. All normal communication within the network will be marked with the unique code used for the Train Link Circuit. In a preferred embodiment, the Train Link Circuit ID is guaranteed to be unique by basing the ID on a hardware address chip installed in the pilot node's communication equipment. Because the Train Link Circuit ID is unique messages from one train's network will not be acted upon by nodes in another train's network.
The Token Type flag indicates whether the RDU received was a severe message token, or SMOKEN. A value of zero implies this message is a normal synchronous message or an asynchronous message, a value of one implies this message is a SMOKEN. The node which changes a packet to a SMOKEN is responsible to set this bit and to make sure that the resulting direction flag for the RDU is correct. An outbound SMOKEN will be rerouted as an inbound SMOKEN by the reversing node.
The Relay Group field defines the relay group associated with the current packet. This value will be zero for the default relay group. It will range between one and twenty one for typical hop configurations. Each outgoing packet is assigned a relay group by the pilot node. All other nodes depend on their network processing to maintain this value in the token as it passes through. Asynchronous packets (high and low priority) may be marked with a relay group of 0�0. The default relay group is 0�0. With reference to FIG. 6, the pilot node may cycle through the relay groups associated with a particular solution. In one embodiment, there are seven defined solutions, and each one is made up of a predefined set of relay groups. Thus, for example, a node using solution three (a three hop solution) would typically cycle between relay groups 4, 5 and 6. If the pilot node decided to switch to a less aggressive solution then it would modify the sequence. It may, when sending a relay group 4 packet decide to switch to a two hop solution, resulting is a pattern such as 4,5,6,4,5,6,4,3,2,3,2,3,2,3 . . .
The Cyclic Redundancy Check (�CRC�) is used to determine if the current packet was received successfully. If the locally calculated packet CRC does not match the embedded packet CRC, the received packet must contain bit errors and should not be divided and redistributed as ADUs.
In a system of the present invention, communications and control are available throughout the entire railway system. Applications can be implemented in the pilot node which will cause status information and control data to be received from the train network and forwarded to: (a) the railway's central control facility; (b) a satellite receiver; (c) a customer's private communication system, etc., merely by providing an appropriate radio link between the locomotive (or the pilot node location) and the desired remote control point. Thus, railway personnel or customers will be able to know not only the location of their railway car but the status of its contents. Similarly, railway personnel or appropriate customer personnel may be permitted to send ADU commands to the pilot node for forwarding via the train's communication system to the appropriate node(s) and application. All such communication between the train's communication system and the �outside� world can be conducted from merely another application executing on the pilot node.
Minimum time=300 msec. Maximum time=t nom+120 msec. (for t nom>180 msec.) where
tnom=No.Hops*(tobtx+tibmcx+2tproc)+(t rev−2tproc)
tibmcx=outbound transmission time
((No.Bytes*8)+423 bits)(1 ms/1000 bits) Reducing the above equations, the pilot node may estimate the maximum time to equal:
(No.Hops*((No.Bytes+8990)/1000)+166)msec. In a system in accordance with a preferred embodiment of the present invention.
In one aspect of the present invention, the network manager at each node receives each packet which is successfully received over the physical link (and correctly addressed, etc.). Each of the packets may contain one or more messages which must be examined and, if appropriate, delivered to various destinations associated with the node. The node may keep a message routing table called an ADU distribution list. Each entry in the list may be termed a destination. Each ADU received, whether it was locally generated ADU or one received from an RDU, is checked against the ADU Distribution list. The ADU Distribution List may be modified by the node as applications are operating at the node. The node will attempt to deliver any received ADU to its addressed location, be it a local address, a subnet address, another address within the node or a address at another node (which must be delivered through RDUs).
The Sub-net Interface 140 appears to the Network Stack 120 as a local application. The Sub-net Interface 140 implements a communication link to external, on-car applications; that is, applications running on the same railcar as the ITC engine, but usually running on another processor. Generally, there will be a hardware link between the processors of the Sub-net Interface 140 and the external applications, such as a standard stop/start asynchronous (UART) link via an RS-485 four wire full duplex connection. Other links, such as a wireless link or another standard/non-standard connection may be used. Thus, the Sub-net Interface 140 can be used to connect the network to external applications on freight cars such as bearing temperature monitors, load monitors, refrigerator car monitors, etc. For example, the Sub-net Interface can be used to implement a link between an operator interface module (display and input device) and the ITC engine in a locomotive.
With continued reference to FIG. 9, the Network Layer (or �Network Relay Layer�) 186 is responsible for the flow of synchronous packets down and back up the train. In the pilot node, the Network Layer 186 formats commands received from the operator interface into messages carried by the packets. In the other nodes, the Network layer 186 is responsible for attaching responses, both solicited and unsolicited, to the packets as they return on the inbound path. The Network Relay layer 186 is also responsible for generating asynchronous packets needed to communicate before the network is fully established or in the situation that the network is not operating correctly.
In the event that the first communications path is not working at that time (due to multipath, faulty antennas, jamming, the train is on a curved path outside the antenna's effective propagation, etc.), the data link manager layer 184 will attempt to send the transmission using the diverse antenna (on the other side of the train). Generally, the RF environment at the diverse antenna will be very different from that seen by the original antenna so there is often little chance that the cause of the first failure of communications will result in a failure on the second attempt. Thus, the antenna diversity, when combined with the retry/acknowledgement scheme provides a robust node to node communication link.
If the packet is not acknowledged after the second attempt, the data link manager layer 184 will cause the selection of another target relay node (the �secondary� target), typically one which represents a shorter required transmission distance. Again, the data link manager layer 184 will attempt to continue the packet on its journey using both antennas, first one then the other.
If the packet is not acknowledged after the second attempt at the second target, the data link manager layer 184 will cause the selection of a third target (the �fallback� target) which is typically the node with the shortest hop distance from the source node. Again, both antennas will be tried, in turn. With this combination of antenna diversity, target diversity and acknowledgement scheme, the probability of one successful transmission of any packet is high.
In another embodiment of the present invention, the pilot node and the relay nodes can self-determine their position within the train through a linking procedure. In the linking procedure, when a node is started, it monitors assigned channel(s) and attempts to link up. For example, if a node is started (or has been disconnected from a network), the node can �wake up� and monitor the linking channel. To save power in a network system installed in a train, the node may also check the brake pipe to determine whether the pipe is pressured and remain �asleep� unless the pressure exceeds a predetermined threshold.
The first node behind the pilot node will detect the pneumatic pulse first (under normal circumstances) and will transmit a message announcing that it is the first node. The node detecting the pneumatic pulse may also sharpen the pulse by venting its supply pipe immediately upon detecting the pulse edge. This technique will help to prevent �smearing� of the pulse edge as it propagates down the train.
Each node that heard the transmission from the first node notes that the first address has ben �taken�, resets its timer, and continues to listen for the pulse and another radio transmission. The next node hears the pulse and repeats the sequence that the first node executed but claims in its transmission the �2� address. This process may continue down the train with each node calling out its number in line as the pressure pulse propagates down the train. Note that each node bases its claimed address on the claim of the node immediately preceding it in the train and does not depend on any node, other than the first one, hearing the transmission from the pilot node. Note also that no absolute or system time is required. Each node needs only to measure elapsed time between events that it observes.
While the train is being linked, each relay node will generally hear the �claimed address� transmission of several of its neighbors. Each node may record such reception in a log to include the claimed address, the delay parameter, the time between its own observation of the pneumatic pulse and the reception of the radio message. Thus information may be passed to the pilot node for its use in determining the relay groups or in redesigning relay groups.
The pilot node can review the data it receives to determine whether anomalies or errors occurred during the linking process. If the time between one node and the next detecting the pneumatic pulse is larger than can be accounted for by the length of the car, a possible �dead� node is indicated. The pilot node can also check the list of linked nodes to a manifest list (if any has been provided). Missing, misidentified and unexpected nodes may be indicated to the operator.
Once all the nodes have been linked, the pilot node may announce a transition to an operation state, commanding the nodes to switch to the operational channel (if a separate linking channel was being used). Generally, after the switch to the operational channel, the pilot node will poll each node to ensure that the node heard the switch and has gone to the operational channel. It after switching to an operational channel, a node does not hear any operational traffic for a predetermined period of time, the node may switch back to the linking channel.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS2748266 *Dec 18, 1952May 29, 1956Bell Telephone Labor IncRadiant energy relay systemUS3628147 *Dec 9, 1969Dec 14, 1971Tokyo Shibaura Electric CoTime-division multiplex mobile communication systemUS4511958 *Oct 26, 1981Apr 16, 1985Patelhold Patentverwertungs- & Elektro-Holding AgCommon bus access system using plural configuration tables for failure tolerant token passing among processorsUS4553723 *Sep 15, 1983Nov 19, 1985Harris CorporationRailroad air brake systemUS4582280 *Sep 14, 1983Apr 15, 1986Harris CorporationRailroad communication systemUS4638298 *Jul 16, 1985Jan 20, 1987Telautograph CorporationCommunication system having message repeating terminalsUS4723737 *Oct 17, 1985Feb 9, 1988Matra TransportProcess and device for transmitting data between vehicles moving over a trackUS4799052 *Jan 13, 1986Jan 17, 1989General Electric CompanyMethod for communicating data on a communication network by token passingUS4947484 *Nov 8, 1988Aug 7, 1990Echelon Systems CorporationProtocol for network having a plurality of intelligent cellsUS5010332 *May 25, 1990Apr 23, 1991Mitsubishi Denki Kabushiki KaishaData transmission apparatusUS5039038 *Oct 3, 1989Aug 13, 1991Harris CorporationRailroad communication systemUS5077554 *Jan 12, 1988Dec 31, 1991Fujitsu LimitedControl system for communication between unitsUS5265832 *Mar 18, 1992Nov 30, 1993Aeg Transportation Systems, Inc.Distributed PTU interface systemUS5311512 *Dec 14, 1992May 10, 1994At&T Bell LaboratoriesMultiple-master digital communication technique utilizing a dedicated contention busUS5347515 *Mar 27, 1992Sep 13, 1994Pittway CorporationMethod and apparatus for global polling having contention-based address identificationUS5351919 *Mar 29, 1993Oct 4, 1994Primetech Electroniques Inc.Trainline communication link using radio frequency signalUS5377938 *Dec 1, 1992Jan 3, 1995Pulse Electronics, Inc.Railroad telemetry and control systemsUS5408679 *Jul 15, 1992Apr 18, 1995Fujitsu LimitedMobile telecommunications system having an expanded operational zoneUS5420883 *May 17, 1993May 30, 1995Hughes Aircraft CompanyTrain location and control using spread spectrum radio communicationsUS5428603 *Sep 15, 1993Jun 27, 1995Hughes Aircraft CompanySynchronous time division multiple access interrogate-respond data communication networkUS5434984 *Mar 24, 1993Jul 18, 1995Alcatel N.V.Priority based access control arrangementUS5435505 *Apr 22, 1994Jul 25, 1995Primetech Electroniques Inc.Electronic communications radio frequency coupler for multi-car vehicleUS5448563 *Jul 19, 1994Sep 5, 1995Mitsubishi Denki Kabushiki KaishaCommunication control methodUS5465081 *Mar 4, 1991Nov 7, 1995Cedar-Dell LimitedMulticomponent wireless system with periodic shutdown of transmitting and receiving modesUS5481532 *Jun 29, 1994Jan 2, 1996General Electric CompanyMobile telecommunications device and serviceUS5481535 *Jun 29, 1994Jan 2, 1996General Electric CompanyDatagram message communication service employing a hybrid networkUS5481539 *Jun 29, 1994Jan 2, 1996General Electric CompanyDatagram communication service over a cellular telephone networkUS5570284 *Dec 5, 1994Oct 29, 1996Westinghouse Air Brake CompanyMethod and apparatus for remote control of a locomotive throttle controllerUS5592482 *Sep 12, 1994Jan 7, 1997Abraham; CharlesVideo distribution system using in-wall wiringUS5592483 *Jun 6, 1995Jan 7, 1997Sharp Kabushiki KaishaData communication apparatus achieving efficient use of the mediaUS5651517 *Jan 11, 1996Jul 29, 1997New York Air Brake CorporationAutomatic train serialization utilizing comparison between a measured parameter and a synchronization signalUS5681015 *Dec 20, 1996Oct 28, 1997Westinghouse Air Brake CompanyRadio-based electro-pneumatic control communications systemUS5720455 *Nov 13, 1996Feb 24, 1998Westinghouse Air Brake CompanyIntra-train radio communication systemUS5835005 *Jul 12, 1995Nov 10, 1998Omron CorporationPower-line data transmission method and system utilizing relay stations* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS6622005 *Mar 3, 2000Sep 16, 2003Ericsson Inc.Methods, systems and devices for cascaded communicationsUS6668216 *May 18, 2001Dec 23, 2003Tc (Bermuda) License, Ltd.Method, apparatus and system for wireless data collection and communication for interconnected mobile systems, such as for railwaysUS6759951Oct 24, 2002Jul 6, 2004General Electric CompanyMethod and system for communicating among a plurality of mobile assetsUS6826514 *May 17, 2000Nov 30, 2004Matthew HendersonMonitoring of controlled mobile environmentsUS6863247May 30, 2003Mar 8, 2005Beltpack CorporationMethod and apparatus for transmitting signals to a locomotive control deviceUS6885916 *Aug 31, 2001Apr 26, 2005Motorola, Inc.Data packet for a vehicle active networkUS6909943 *Sep 9, 2003Jun 21, 2005Power Dsine, Ltd.System for power delivery over data communication cabling infrastructureUS6961780 *May 29, 2001Nov 1, 2005Nokia Mobile Phones, Ltd.Suspend stateUS6975927 *Dec 2, 2002Dec 13, 2005Beltpack CorporationRemote control system for locomotive with address exchange capabilityUS6997418 *Jul 26, 2000Feb 14, 2006Ge-Harris Raliway Electronics, L.L.C.Methods and apparatus for testing a train control systemUS7009501 *May 22, 2003Mar 7, 2006Disney Enterprises, Inc.System and method of optical data communication with multiple simultaneous emitters and receiversUS7023811 *Jan 17, 2001Apr 4, 2006Intel CorporationSwitched fabric network and method of mapping nodes using batch requestsUS7038597Oct 24, 2002May 2, 2006General Electric CompanyRailroad distributed power communication system and methodUS7043577 *Aug 27, 2002May 9, 2006General Electric CompanyAuto-detecting universal appliance communication controllerUS7069122 *Mar 7, 2003Jun 27, 2006Control Chief CorporationRemote locomotive controlUS7126985Jun 4, 2002Oct 24, 2006Cattron Intellectual Property CorporationMethod and apparatus for assigning addresses to components in a control systemUS7164709Jun 4, 2002Jan 16, 2007Cattron Intellectual Property CorporationMethod and apparatus for assigning addresses to components in a control systemUS7167510 *Mar 30, 1999Jan 23, 2007Cattron Intellectual Property CorporationMethod and apparatus for assigning addresses to components in a control systemUS7203228Dec 19, 2003Apr 10, 2007Cattron Intellectual Property CorporationMethod and apparatus for assigning addresses to components in a control systemUS7395141Sep 12, 2007Jul 1, 2008General Electric CompanyDistributed train controlUS7455370 *Nov 29, 2005Nov 25, 2008New York Air Brake CorporationBrake pipe control system with remote radio carUS7484169 *Feb 15, 2006Jan 27, 2009General Electric CompanyImplicit message sequence numbering for locomotive remote control system wireless communicationsUS7577668Nov 19, 2003Aug 18, 2009Hitachi, Ltd.Information transmission system and information transmission methodUS7664459Mar 23, 2005Feb 16, 2010General Electric Co.On-board message repeater for railroad train communications systemUS7792089 *Jul 31, 2002Sep 7, 2010Cattron-Theimeg, Inc.System and method for wireless remote control of locomotivesUS7801166 *Jan 6, 2005Sep 21, 2010Alstom Canada Inc.Ruggedized analog front-end for a network communicative device in a railway-like environmentUS8140658 *Oct 4, 2000Mar 20, 2012Borgia/Cummins, LlcApparatus for internetworked wireless integrated network sensors (WINS)US8170732Mar 17, 2009May 1, 2012General Electric CompanySystem and method for operating train in the presence of multiple alternate routesUS8180869 *Mar 16, 2010May 15, 2012Russell FishDistributed means of organizing an arbitrarily large number of computersUS8214864Jun 8, 2006Jul 3, 2012Mitsubishi Electric CorporationOn-train video information delivery control and display systemUS8224237Jan 25, 2010Jul 17, 2012General Electric CompanyMethod and apparatus related to on-board message repeating for vehicle consist communications systemUS8229350Jan 25, 2010Jul 24, 2012General Electric CompanyMethod and apparatus related to on-board message repeating for vehicle consist communications systemUS8380361 *Jun 16, 2008Feb 19, 2013General Electric CompanySystem, method, and computer readable memory medium for remotely controlling the movement of a series of connected vehiclesUS8532850Jan 7, 2010Sep 10, 2013General Electric CompanySystem and method for communicating data in locomotive consist or other vehicle consistUS8583299Dec 29, 2010Nov 12, 2013General Electric CompanySystem and method for communicating data in a train having one or more locomotive consistsUS8655515Nov 29, 2010Feb 18, 2014General Electric CompanyCommunication system for a rail vehicle consist and method for communicating with a rail vehicle consistUS8655517Apr 8, 2011Feb 18, 2014General Electric CompanyCommunication system and method for a rail vehicle consistUS8667116Sep 30, 2005Mar 4, 2014Robert Bosch GmbhMethod and system for providing reliable communication with redundancy for energy constrained wireless systemsUS8702043Sep 28, 2010Apr 22, 2014General Electric CompanyRail vehicle control communication system and method for communicating with a rail vehicleUS8781671 *Feb 21, 2006Jul 15, 2014New York Air Brake CorporationOn-board brake system diagnostic and reporting systemUS8798821Jul 25, 2011Aug 5, 2014General Electric CompanySystem and method for communicating data in a locomotive consist or other vehicle consistUS8825239Apr 8, 2011Sep 2, 2014General Electric CompanyCommunication system and method for a rail vehicle consistUS20090312890 *Jun 16, 2008Dec 17, 2009Jay EvansSystem, method, and computer readable memory medium for remotely controlling the movement of a series of connected vehiclesUS20110115284 *Nov 13, 2009May 19, 2011Head Thomas SWheel slip protection systemUS20110170450 *Sep 23, 2008Jul 14, 2011Markku JunttiCooperative transmission in wireless communication systemUS20120014250 *Mar 16, 2010Jan 19, 2012Russell FishDistributed means of organizing an arbitrarily large number of computersUS20130041547 *Oct 19, 2012Feb 14, 2013General Electric CompanySystem, method, and computer software code for distributing and managing data for use by a plurality of subsystems on a locomotiveUS20130103811 *Apr 6, 2011Apr 25, 2013Volker BlaschkeMethod for providing a communication for at least one deviceUS20140081487 *Sep 20, 2012Mar 20, 2014Wabtec Holding Corp.System and Method for Addressing a Pneumatic Emergency in a Helper LocomotiveEP1422833A2Nov 19, 2003May 26, 2004Hitachi Information &amp; Control Systems, Inc.Information transmission system and information transmission methodEP1770907A1 *Sep 26, 2006Apr 4, 2007Robert Bosch GmbHMethod and system for providing monitoring with redundancy for energy constrained wireless systemsEP1903800A1 *Jun 8, 2006Mar 26, 2008Mitsubishi Electric CorporationTrain-installed video information delivery control display systemEP2088684A1Nov 19, 2003Aug 12, 2009Hitachi, Ltd.Information transmission system and information transmission methodEP2088685A1Nov 19, 2003Aug 12, 2009Hitachi, Ltd.Information transmission system and information transmission methodWO2005120925A2 *May 21, 2004Dec 22, 2005Gen ElectricLocomotive control system and methodWO2012074680A1 *Nov 8, 2011Jun 7, 2012General Electric CompanyCommunication system for a rail vehicle consist and method for communicating with a rail vehicle consist* Cited by examinerClassifications U.S. Classification340/933, 340/425.1, 455/7, 246/167.00R, 455/11.1, 340/3.5, 370/315International ClassificationB61L15/00, H04L12/403, B61L3/12, H04L1/16, H04L12/56, H04L1/18, H04L1/00Cooperative ClassificationH04L45/20, H04W28/04, H04L2001/0092, H04W88/04, B61L15/0081, H04L12/40163, B61L15/0027, H04L12/42, B61L27/0038, H04L45/00, B61L25/025, B61L3/125, H04L12/403, H04W28/26, B61L25/021, H04L1/1887, H04L2012/40293, H04L1/1657, H04L1/188, B61L27/0077, H04W84/005, H04W40/22, H04L1/16, H04W40/06, H04W40/02, B61L25/023, H04L12/40182, H04L1/1803European ClassificationB61L27/00C, H04L12/40R1A, H04L45/00, H04L45/20, H04L1/16F11, H04L12/403, H04L1/18A, H04L1/16, H04L1/18T5, B61L25/02A, H04L12/42, H04L12/40P3, B61L3/12B, B61L15/00H, B61L15/00B1, B61L25/02B, B61L25/02C, B61L27/00GLegal EventsDateCodeEventDescriptionJan 10, 2014REMIMaintenance fee reminder mailedMar 17, 2010SULPSurcharge for late paymentYear of fee payment: 7Mar 17, 2010FPAYFee paymentYear of fee payment: 8Jan 11, 2010REMIMaintenance fee reminder mailedSep 27, 2005FPAYFee paymentYear of fee payment: 4Dec 14, 2004ASAssignmentOwner name: GE TRANSPORTATION SYSTEMS GLOBAL SIGNALING, LLC, NFree format text: CHANGE OF NAME;ASSIGNOR:GD HARRIS RAILWAY ELECTRONICS, LLC;REEL/FRAME:015442/0767Effective date: 20010921Owner name: GE TRANSPORTATION SYSTEMS GLOBAL SIGNALING, LLC ONFree format text: CHANGE OF NAME;ASSIGNOR:GD HARRIS RAILWAY ELECTRONICS, LLC /AR;REEL/FRAME:015442/0767May 12, 1998ASAssignmentOwner name: GE-HARRIS RAILWAY ELECTRONICS, L.L.C., FLORIDAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DARBY, ALBERT DONALD, JR.;PELTZ, DAVID;HEFNER, MARK;AND OTHERS;REEL/FRAME:009182/0933;SIGNING DATES FROM 19980420 TO 19980505RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google