WO2015100425A1 - System and method for detecting operational anomalies in train consists and railcars - Google Patents

Abstract

A system for monitoring railcar and tram consist operational parameters and detecting anomalies in the operation and condition thereof using sensors to feed data to a distributive complex event processing engine.

Description

SYS TEM AND METHOD FOR DETECTING

OPERATIONAL ANOMALIES IN TRAIN CONSISTS AND RAIL-CARS

Related Applications

[0001] The application claims the benefit of U.S. provisional application 61/920,700, filed

December 24, 2013, the entirety of which is hereby incorporated herein by reference.

Field wf the Invention

[0002] The present invention relates to the field of railcar and train safety

management, and is specifically directed to a system and method for

continuously collecting and analyzing operational parameters of railcars and train consists to detect anomalous operating conditions.

Background of the invention

[0003] Current prior art monitoring of bearings and wheel to rail interactions on train

consists has been managed primarily through the use of wayside detectors located throughout the rail system, which includes detectors for monitoring the temperature of railcar wheel bearings, and wheel impact l oad detectors which identify damaged wheels by monitoring impacts of wheels on the rails.

These detectors are installed at fixed points in the rail network.

[0004] Since their introduction, these methods have provided railroad operators with

information to improve railcar and train consist performance. However, these detectors lack the benefits of a wireless network capable of transmitting

information and data regarding operational anomalies, such as when a railcar derails, the condition of the bearings and wheels when not in range of

detectors, and wheel damage. Further, these prior methods do not provide a mechanism to continuously monitor assets at any location in the rail network. [0005] Wheel damage in the railroad industry is responsible for significant

maintenance costs related to the raiicar wheels, raiicar body, raiicar components, rail tracks and rail ties. Wheels that are slid flat have an. uneven section on the wheel where it comes into contact with the rail. As the wheel rotates this section creates an abnormal, impact pattern, which, can cause further damage to the wheel, damage to the raiicar and damage to the rail and track structure.

[0006] Presently, however, there is no reliable system for continuously monitoring

the temperatore of wheel bearings or wheel to rail interac tions where a wheel impact load detector is not. installed on a section of rail or in the area between detectors. Accordingly, it is desirable to provide a system and method for the real-time, on-board monitoring of various operational parameters of a raiicar and/or train consists, and for analyzing the readings in real time to predict or timely detect anomalous operational conditions.

Summary of the Invention

[0007] The system presented herein addresses the deficiencies in prior art monitoring systems for ratlcars and train consists. The system consists of a hierarchical arrangement of components which provide a distributed data analysis capability that is capable of detecting operational anomalies at various levels of the hierarchy, and which provides for the flow of data, events and. alerts to a central point.

[0008] At the lowest level of the hierarchy, each rai icar is equipped with multiple

wireless sensor nodes {referred to in the singular as a "W^'SN"), which are arranged in a mesh network controlled by a communication management unit ("C U"), usually on the same raiicar, referred to herein as a railcar-based mesh network. The wireless sensor nodes collect data regarding various operational parameters of the raiicar and are capable of detec ting certain anomalies based on the collected data. When anomalous operational data is detected, an alert may be raised and the dat may be communicated to the commun cation management unit located cm the railcar. Although mesh networks are used in the embodiments illustrated herein, other types of network topologies may be used.

[0009] The communication management units located on each railcar are also

arranged in a mesh network which is controlled by a powered wireless gateway, typically located in the locomotive. This is referred to herein as a train-based mesh network. Again, although mesh networks are used in the embodiments illustrated herein, other types of network topologies may be used.

[0010] The train-based wireless mesh network communicates the length of the train

consist and delivers information about the raikars to a powered host or control point, such as the locomotive or an asset with access to a power source and to a railroad remote operations center.

Brief Description of the Drawings

[0011] The present invention will be more fully and completely understood from a reading of the Detailed Description of the Invention in conjunction with the drawings, in which;

[0012] Figure 1 is a schematic of a railcar 103 equipped with a communication

management unit (CMU) .101 and a plurality of wireless sensor nodes (WSNs) 104 installed thereon, forming, a railcar-based mesh network 105.

[0013] Figure 2 is a schematic of a train-based mesh network with two railcars 103 each equipped with a CMU 101 and multiple WSNs 104, a railcar 103 equipped with just a CMU 101 (no WSNs), a railcar 103 without a CMU or WSN, and a powered wireless gateway device 102 installed on a locomotive 108. [001 ] Figure 3 shows a tram-based mesh network 107 and various means of communicating data off-train.

[0015] Figure 4 is an exploded view of a first variety of WSN 104 which can be used, for

example, for monitoring bearing temperature and wheel acceleration.

[0016] Figure 5 is an exploded view of a second variety of WSN 104 which can be

used, for example, for monitoring railcar body acceleration, and which can include a temperature sensor (not shown) for monitoring temperature.

[0017] Figure 6 shows the WSN .104 of Figure 4 installed on a railcar wheel, bearing fitting i l l ,

[0018] Figure 7 is a flow chart showing the conditions under which longitudinal

impact acceleration event processing is enabled and disabled.

[001.9] Figure 8 is a flow chart showing the conditions under which vertical and

lateral hunting acceleration event processing is enabled and disabled.

[0020] Figure 9 is a flow chart showing the conditions under which derailment

monitoring event processing is enable and disabled.

[0021 ] Figure 10 is a flow chart showing the conditions under which wheel damage or vertical impact event processing is enabled and disabled.

[0022] Figure 1 1 is a flow chart showing the conditions under which bearing

temperature event processing is enabled and disabled.

[0023] Figure 12 is an architectural diagram showing a generalized model for

implementation of the data analysis portion of a WSN 104,

[0024] Figure 13 is a specific implementation of the model shown in Figure 12

directed to detec tion of railcar body events.

[0025] Figure 14 is another specific im lementation of the model shown in Figure 12, this one directed to detection of wheel bearing events. [0026] A ralkar. as the term is used herein, may be a single railcar 103, see Fig. 1.. or may consist of two or more railcars 103 which are permanently connected, often referred to by those of skill in the art as a "tandem pair", "three-pack", "rive-pack", etc,

[0027] A train consist, shown in the drawings as reference number 109, see Fig. 2, is

defined as a connected group of railcars 103 and locomotives 108.

[0028] A communication management unit ("CMU"), shown in the drawings as reference- number 101 , is preferably located on a railcar 103 and controls the railcar-based mesh network 105 {defined below) overlaid on railcar 103 which may consist of one or more individual railcars J 03 which are permanently connected together. The CMU 101 hardware preferabl includes a processor, a power source (e.g. a ^'battery, solar cell, energy harvester, or internal power-generating capability), a global navigation satellite system (G^' SS) device such as a global positioning system ("GPS^"5} receiver, Wi-Fi, satellite, and/or cellular capability, a wireless

communications capability for maintaining the railcar-based mesh network 105, wireless communication with a train-based mesh network 107 and, optionailv, one or mote sensors, including, but not limited to, an acceleromeier 404, gyroscope, or temperature senso 406.

[0029] The CMU 101 supports one or more WSNs 104 (defined below) in a mesh network

configuration using open standard protocols, such as the IEEE 2.4 GHz 802.15.4 radio standard. Additionally, the CMU 101 is also a member of a train-based mesh network 107, which consists of the CMlJs 101 -from all enabled railcars 103 in the train consist 109, controlled by a powered wireless gateway 102, typically located on a locomoti e 108. The CMU 101 thus supports four functions: 1 ) to manage a low- power railcar-based mesh network 1 5 overlaid on a railcar 103; 2) to consolidate data from one or more WSNs 104 in the railcar-based mesh network 105 and to apply logic to the data gathered to generate warning alerts to a host such as a locomotive 108 or remote railroad operations center 120; 3) to support built-in sensors, such as an aecelerorneter 404, within the CMU 1.01 to monitor specific attributes of the railcar 103 such as location, speed, and accelerations, and to provide an analysis of this data to generate alerts; and 4) to support bi-directional communication upstream to the host or control point, such as a locomotive 108 and/or an off-train monitoring and remote railroad operations center 120, and

downstream to one or more WSNs 104, located on the railcar 103. CMUs 101 may communicate wirelessly to a powered wireless gateway (FWG 102 as defined below) in a mesh network configuration, or may be configured to communicate through a wired connection, for example, through the ECF (electronically controlled piieumatic) brake system. Those skilled in the art will appreciate that GPS is j ust one form of a global navigation satellite system (GNSS). Other types of G SS include GLONASS and BeiDou with others in development. Accordingly, although GPS is used in the embodiments described herein, any type of GNSS system or devices may be used.

[0030] The CMU 101 is capable of receiving data and/or alarms from one or more WSNs

104 and is capable drawing inferences from this data or alarms regarding the performance of ailcar 3 3. and of transmitting data and alarm information to a remote receiver. The CMU 101 is preferabl a single unit that would serve as a communications link to other locations, such as a powered wireless gateway 102 (preferably located in locomotive 108), or a remote railroad operations center 120, and have the capability of processing the data received.. The CMU 101 also communicates with, controls and monitors WSN 104 in the local raikar-based mesh network 105,

[0031] A powered wireless gateway ("PWG"), shown in the drawings as reference number

102 (see, e.g., Fig. 2), is preferably located on a locomotive 1 8 or elsewhere on a train consist 109 where there is a source of external power. It typically will include a processor; a GPS receiver; one or more sensors, including, but not limited to, an acceierometer 404, gyroscope, or temperature sensor 406; a satellite and or cellular communication system; local wireless transceiver (e.g. WiFi); an Ethernet -port; a high capacity mesh network manager and other means of communication. The PWG 1 2 will have power supplied by the locomotive 108, if located on a powered asset, such as a locomotive 108, or will derive its power from another source, for example, from a solar power generator or from a high-capacit battery. The PWG 102 controls a train-based mesh network 107 overlaid on. a train consist 109, consisting of multiple CMUs 101 from each railcar 103 in a train consist 109.

The components and configuration of the PWG 102 are similar to that of a CMU 1.01, with the exception that the PWG 102 typscaiiy draws power from an exteraai source, while the CMU 1.01 is self-powered. Additionally, the PWG 102 collects data and draws inferences regarding the performance of the train consist 109, and train-based mesh network 107, as opposed to CMUs 101, which draw inferences regarding the performance of individual railcars 103 and railcar-based mesh network 105 or 1 18. A railcar-based mesh network shown in the drawings as reference number 105, see, e.g.. Figs. 1 and 2, consists of a CMU 101 on a railcar 103, wh ich is part of and manages a railcar-based mesh network 105 of a plurality of WSNs 104, each deployed, preferably on the same railcar 103.

A wireless sensor node ("WSN"), shown in the drawings as reference number 104, see, e.g., Figs. .1 and 2, is located on a railcar 1.03, and provides the functions of collecting data from internal sensors and analyzing the data collected from the sensors to determine if the date needs to he transmitted immediately, held tor later transmission, or aggregated into an event or alert. The WS 104 is used for sensing a. parameter to be monitored (e.g. temperature of bearings or ambient air) or status (e.g., position of a hatch or hand brake). In a preferred embodiment, each WSN 104 is equipped with one or more acceierometers or gyroscopes and one or more

temperature sensors. Examples of WSNs 104 are disclosed in published U.S. patent application 2013/0342362, the disclosure of which is hereby incorporated by

reference herein. A typical WSN 104 is shown in exploded view in Figure 4 and

Figure 5 and will now be explained in more detail.

With reference to Figure 4, an example of a first variety of WSN 104 is now described. T he WSN 104 shown in Figure 4 is configured and tuned to

detect certain kinds of acceleration and temperature events and is typically

located on the wheel bearing fitting 1.1.1 of railcar 1.03, where it is likely to be

subjected to various degrees of accelerations and. where it can easily collect data regarding the temperature of the wheel bearing. The components of

WSN 104 are contained in a housing 400 having an enclosure 400a and an enclosure base 400b. Preferably, housing sections 400a, 400b are composed of a bard plastic resistant to environmental damage, such as a tiV rated polymer, e.g., a polycarbonate/ ABS blend, and when fully assembled is weatherproof. After the various components are installed within the housing as described below, a potting material (not shown) is provided through openmgs in the housing 400 to isolate, encapsulate and environmentally seal the components within. Such materials include epoxies, polyurethanes and silicone compounds. A flexible urethane suitable for electrical use and through which wireless signals can be transmitted is preferred, it has been found that the particular potting material used is also critical in the proper inning of the WSN 04 to detect various types of accelerations. A potting material having a durometer of 59 Shore 00 is preferred.

[0036] Additionally, a mechanical filter 410 consisting of upper sections 410a and lower sections 410b further serve to mechanically filter high and low frequency types of accelerations that are considered noise and which are preferably removed from the signal of interest. Preferably, these components are composed respec tively of silicone of duroraeter 70 Shore A (the upper filter sections 41 a) and 30 Shore A (the lower filter sections 410b) in view of the differences of the surface areas of each sectio and this affect on the filtering characteristics.

[0037] in a preferred embodiment, each WS 1.04 may have one or more

accelerometers 404 and one or more temperature sensors 406. ^"The tuning of WSN 104 is accomplished by a combination of the selectio of the potting material the durometer of upper and lower silicone mechanical filtering elements 4.10a and 410 b, and software filtering performed by software executing on a processor on main PC board 402a. The software filter used is a digital filter to decrease noise from unwanted acceleration frequencies and increase sianals from acceleration frequencies of interest.

[0038] Temperature sensor 406, includes a heat transfer element which extends through an opening 406a i the enclosure base 400b, and opening 406b in the filter section 410b. Preferably, the heat transfer element is a copper plug. Tins configuration, is preferred for monitoring the surface temperature of the surface to which WSN .104 is attached., as the heat transfer element will make contact with the surface. In preferred embodiments of the invention, the temperature sensor 406 is a thermistor, thermocouple or silicone temperature sensor which are ideal for electronic circuits. In this embodiment, WSN 104 will be mounted to place the heat transfer element in. thermal communication with the portion of the raikar 103 for which a temperature reading is desired. Additionally, the lower sections 410b of the mechanical filter are of a suitable thickness to create an air gap between the enclosure base 400b and the surface to which the WSN 1 4 is mounted. The lower sections 10b of the mechanical filter and the air gap create good thermal protection and low heat transfer from the surface to which the WSN 104 is mounted. This thermal protection keeps the electronics (all except for the temperature sensor 406) and the power source from being exposed to excess and potentially damaging heat. WSN 104 may also be equipped with additional temperature sensors (not shown) for sensing the ambient temperature.

[0039] hi the preferred embodiment, self-taping screws 415 serve to attach WSN

104 to the railcar 103 and to hold upper and lower portion 10a and 410b of mechanical filter i place. Spacers 400c which fit within the screw openings 410c of the filter pads are chosen in length to control the amount of compression force on the filter sections 410a and 4.10b due to the tightening of the screws 415. Without the spacers 400c, the filtering characteristics of the lllters could be changed due to compression from over tightening of the screws 415. The spacers are chosen from a suitably stiff material

[0040] As one of ordinary skill would recognize, the configuration of WS s 104 ma vary with respect to the number and types of sensors. Virtually any type of sensor could be used, including, for example, a temperat ure sensor 406, a pressure sensor, a load cell, a strain gauge, a hall effect sensor, a vibration sensor, an accelerometer 404, a gyroscope, a displacement sensor, an. inductive sensor, a piez o resistive microphone or an ultrasonic sensor, depending on the specific operational parameter that is desired to be

monitored. hi addition, the sensor may be a type of switch, including, for example, reed switches and limit switches. An example of another type of mote sensor which uses a sixain gauge, e.g. a hand brake monitor sensor, is described in U.S. patent publication 2012/004681 1 (US Patent Application 12/861 ,713 filed August 23, 2010), the disclosure of which is hereby incorporated herein by reference.

[0041] Electrical circuitry' is provided for the operation of WSN 104. The eiectrical circuitr includes the components and wiring to operate and/or receive and process the signals from, the sensors. This can include, but is not limited to, analog and digital circuitry, CPUs, processors, circuit boards, memory, firmware, controllers, and other electrical items, as required to operate the accelerometers and temperature sensors 406 and to process the information as further described below.

[0042] in the illustrated embodiment in Figure 4, the circuitry includes a main board

402a which includes the communications circuitry, antennae and microprocessor and a daughter board 402b which includes circuitry to read the data from accelerometers 404 and temperature sensors 406. Main board 402a, daug er board 402b or the sensors ma also include a processor executing firmware to provide intelligence sufficient to perform low-level analysis of the data, and may accept parameters from outside sources regarding when alarms should be raised, as described, below,

[0043] Each WSNS 104 also includes circuitry for wireless communications and a long-term power source 414(e.g. a battery, solar cell, energy harvester, or internal power-generating capability), preferably a military grade lithium- t^'hionyl chloride battery. The circuitry also provides power conditioning and management functions and ma include a feature to conserve battery life which keeps WSN 104 in a standby state and periodically wakes WSN Ϊ04 to deliver readings from the sensors.

1.0 [0044] Figure 5 sho ws an exploded view of a second variety of WSN 104, which is preferably .mounted on the body of raikar 03. The variety of WSN 104 shown in Figure 5 is substantially identical to the variety shown in Figure 4

(and thus similar elements are identified with the same reference number), with the following differences. First, as this variety of WSN 104 will be mounted to the body of raikar 103, where it is likely to be subjected to more gentle accelerations, there is no need for the additional mechanical filtering provided by mechanical filters 410 of Figure 4. Thus, using four screws, two on each side, and give that this WSN is not exposed to the more violent accelerations of the other variety, the screws or holts of this second variety can be smaller in diameter. Second, the illustrated embodiment does not include a temperature sensor 406, although one or more temperature sensors 406 may be provided with a heat transfer element, as discussed above for the first variety, extending ihrough an opening in the housing to sense the desired temperature, e.g., the ambient temperature. Lastly, although this variety of

WSN 104 includes an accelerometer 404 like the prior described WSN 104 of Fig. 4, it preferably will be programmed with different firmware to detect different types of acceleratio events, as discussed below. As understood by one of ordinary skill, the WSNs of both varieties could also contain just a temperature sensor, although there would be no need for filtering as

described with reference to Fig, 4.

[0045] Individual WSNs 104 are mounted on the areas of interest on a raiicar 103. As an example. Figure 6 shows WSN 104 of the type shown in Fig, 4 mounted to a roller bearing fitting 1 1 of a raiicar wheel bearing of a raiicar 103. The unit may be attached using a thermally conductive epoxy adhesive between the heat transfer element and the roller bearing fittin 1 I 1 to ensure good heat transfer to the temperature sensor 406, and mechanical fasteners such as self-tapping screws 415 to hold WSN 104 in place. in broad terms, with reference to Figs, 1 and 2. the present invention pro vides a novel means for monitoring the performance and operation of a railcar 103 and train consist 109. This includes a plurality of sensors 104 deployed on the railcars 103 in the consist 109 for sensin various operational parameters of the railcar 1 3 and distributed complex event processing (DCEP) engine, which is a hierarchical system for collecting and analyzing the data and for communicating data, events and alerts to a final destination where they can be acted upon.

The DCEP is responsible for implementing the intelligence used to draw conclusions based on the data .collected from WSNs 104, CMUs 101 and PWGs 102. Preferably, the data, processing platform is distributed among all WSNs 104, CMUs 1.0.1 and. the PWG 102 on the locomotive 1 8, as well as utilizing a cloud-based infrastructure optimized to work closely with train-based mesh networks 107, in conjunction with a variety of data streams from third-party providers or external sources.

With further reference to Fig. 1 of the drawings, a railcar-based mesh network is shown generally as reference number 105. Railcar-based mesh network 105 comprises a CMU 101 installed on a .railcar 103 and one or more WSNs 104 installed on the same railcar 103, Railcar 103 may consist of one or more individual railcars 103, which are permanently connected together. The railcar-based mesh network 105 is a critical component in the processing of events and alerts on the railcar 103. CMU 101 and WSNs 104 work together to collect and analyze the data collected from sensors in the WSNs 104. CMU 101 controls the raifcar-based mesh network 105 on railcars 103 and is able to configure one or a more WSNs 104 in a local mesh network to transmit listen, or sleep at precise times, or to change the parameters under which WSNs 104 operate and detect events.

With further reference to Figure 2, a schematic of a train-based mesh

network .107 is shown with, two railcars .103 each equipped with a CMU 101 and multiple WSNs 104 installed near the wheel bearings of the railcar 103 , a railcar 1 3 equipped with just a CMU 101 with no WSNs 104 attached, a

railcar 1 3 without a CMU 1 1 , and a PWG 102 installed on a locomotive

108. The CMU 1 1 and multiple WSNs 104 installed on railcars 103 form a

1.2 ratlcar-based mesh network Ϊ05 and communicate with the PWG 102 on a host or control point, such as a locomotive 108 or other asset, forming the train-based mesh network 1 7. The railcar-hased mesh network for the railcar 103 having a CMU 101 only and no WSNs is designated 1 18.

[0050] if an alert or event condition is detected by a WSN 104, as described i more detail below, a message is forwarded by WSN 104 to CMU 1.01 for further analysis and action, for example, to confirm or coordinate alert or event conditions reported by one WSN 104 with other WSNs 104 in the railcar- based mesh network 105. If an alert or event, is confirmed by CMU 101 , a message i sent to PWG 102 installed on an asset, preferably wit access to a power source and/or to an off train monitoring and remote railroad operations center 120.

[00 1] CMU 101 on each railcar 103 is capable of supporting an optional, global navigation satellite system (G^'NSS) sensor to determine location, direction and/or speed of railcar 103. This information can be osed to determine whether or not WSNs 1 4 should be look ing for certain types of events. For example, it is fruitless for a WSN 104 to attempt to detect derailments when the train consist 109 is stationary. Additionally, the PWG 102 can send instructions for the CMU 101 to start or stop looking for certain types of events. Additionally, CMU 101 on each railcar 103 is capable of using built- in sensors and or managing a railcar-based mesh network 105 on the railcar 103 to generate messages that need to be sent to a host or control point, such as a locomotive 108.

AI ert and Even D etectle n and Rep or tin a

[0052] Each WSN 104 is capable of analyzing the data collected from its sensors in determining if the an event or alert message, as well as the data should be uploaded to the next higher level in the hierarchy, in this case CMU 101. With respect to acceierometers 404, each WSN 104 can be programmed with multiple thresholds for peak and root mean square (RMS) level of magnitude values acceleration readings received from the one or more acceleromeiers 404. When one of the peak or RMS acceleration thresholds are exceeded, it is an indication of a possible event or alert condition, and a message is generated and sent to CMU 1.01 in the same railcar-based mesh network 105. The thresholds for each variety of WSN 104 may be dynamically programmed by commands either generated internally or received externally from CMU 101.

[0053] In the preferred embodiment, WSNs 104 are programmed, with thresholds which indicate specific types of alerts or events . For the W SNs 104 mounted on wheel roller bearing fittings 1 1 1, these units may generate a possible derailmen t message, a vertical impact message or a wheel damage message depending upon the threshold which is exceeded. For WSNs 104 located on the body of raiicar 103 , examples of messages generated are longitudina l impact extreme lateral raiicar dynamics, extreme vertical raiicar dynamics, vertical hunting and lateral hunting. In the illustrated embodiments, the WSNs 1.04 do not determine if each of the possible conditions actually exists, litis determination is preferably made at the next level up of the hierarchy, at CMU 101, which utilizes the readings from multiple WSN 104 to make a determination that an actual event has occurred. As would be readily realized by one of skill in the art, different thresholds suggesting the occurrence of other types of events may be programmed into WSNs 104.

[0054] Regarding the temperature sensors 406 in each WS 104, which are capable of sensing the temperature of the surface on which a WSN 104 is installed and/or the temperature of ambient air around the WSN 104, the temperature readings from each WSN are periodically reported to the CMU 101. The CMU 101 must coordinate the collecting of temperature data from all WSNs 104 in the railcar-base mesh network 105 and, as such, the period for reporting of temperatures, as well as the timing of the reporting of temperature data is programmed for each WSN .1 4 by CMU 101. [0055] Each WSN 104 is able to make a determination of when to report data that ma indicate a possible event or alarm condition to CMU 101. CMU 101 is able to collect such notifications from each WSN 104 under its control and coordinate the data to make a final determination as to whether or not an event or alarm condition actually exists. For example, in the preferred embodiment each wheel roller bearing fitting 1 1 3 in a railcar 103 will have a WSN 104 attached thereto to monitor accelerations and temperature. Thus, on a typical railcar .103 having two trucks (bogies), each with, two axles., a total of eight WSNs 104 mounted to wheel roller bearing fitting 1 1 1 will be present. In addition, and also in accordance with a preferred embodiment, each railcar 103 will preferably have an additional WSN 104 located at each end of the railcar 103 attached directly to the railcar body. CMU 101 also may include acceleration, temperature or any other type of sensors and may replace one or mote of the WSN 104s on the body of railcar 1.03 or may be supplemental to the set of WSN 104s thai are installed on the body of railcar 103. The raiicar-based mesh network 105 may include any combination of WS^'Ns 104, including a configuration wherein the CMU 101 is the only component installed on the railcar 103. Additionally, CMU 101 may also monitor WSNs 104 installed on other railcars 103 such as in the case where railcar 103 may consist of one or more individual railcars 103 which are permanently connected together.

[0056] In the preferred embodiment, the logic in the CMU 10.1 is capable of

analyzing both acceleration and temperature events received from each of the WSNs 104 under its control and detennining if an alarm or event condition actually exists. It should be noted that acceleration events are independent of temperature events and the CMU 101 may be configured to either analyze only acceleration events, or to analyze only temperature events. Thus the CMU 101 , and WSNs 1 4 under its control, form a distributed event processing engine which is capable of determining various types of events. [0057] The acceleration events which CMU 101 is capable of detecting in the preferred embodiment wilt now be discussed in greater detail. It should be noted that when CMU 101 determines that an alarm or event has occurred, a message is sent to the next level in the hierarchy that is either to a PWG 102 located elsewhere on train consist 109 or off train consist 109 to a remote railroad operation center 120, depending upon the severity of the event and the need to immediately address the event, perhaps by altering the train consist's 10 operating condition. Examples of events that, can be analyzed using the features described above are provided below.

[0058] Derailment ~ A derailment event is regarded as a high priority type of event

and is an example of the type of events that can be analyzed by the illustrated embodiment. When a derail message is received from a WSN 104, the CMU 101 starts a derailment processing timer and also immediately generates a possible derailment message to the PWG 102. CMU 1 1 then waits to determine if any other WSNs 104 are generating derailment messages. If other WSNs 104 have generated derailment messages within predetermined time interval, they are all presumed to have originated f om the same physical event and a derailment message is generated and sent to PWG 102.

[0059] Figure 9 is a ^'flow chart showing the conditions under which the derailment event is enabled or disabled. At 900, the system is initialized and, at 902, the system is placed in a waiting state in anticipation of the railcar 103 moving, wherein the derail event is disabled. It should be noted thai derailment events are disabled when the railcar 103 is stationary. At 904, the system checks to see if the railcar i 03 is stationary and, if it is, it returns to the waiting state at 902. If the railcar 103 is moving control moves to 906 where the derailment event is enabled. The derailment event is enabled by having CMU 1. 1 send a .message to each of the WSNs 104 under its control. At 908, the system is again placed in a waiting state; however, the derailment event is now enabled. At 910, the system, queries as to whether a derailment, has been detected and, if not, control proceeds to 914 where the system queries as to

1.6 whether the railcar 103 is stationary. If the railear 103 is moving, control returns to 90S, the system waiting state, having the derailment event enabled. If at 910 a derailment is detected, control proceeds to 12 where a system report of a derailment is made and control then proceeds to 914 as before, if. at 914, it is determined that the railcar 103 is again stationary, the derailment event is disabled at 916 and control returns to 902, where the system waits in a stale where the derailment event is disabled.

[0060] Vertical Impact - A vertical impact message is regarded as a medium pri ority

type of event. When a vertic al impact event is received, from a. WSN 104, CMU 10.1 starts a vertical impact processing timer during which CMU 1.01 waits to see if any other vertical impact events are received from other WS 1 4s. Depending on which side of the railcar 103 vertical i mpact messages are being generated, it can be determined, for example, thai broken rail or other track condition may exist

[0061 Wheel Damage -- A wheel damage message is regarded as a low priority type of event. When a wheel damage event is received from a WSN 104, CMU 101 starts to listen for additional wheel damage events from the same WSN 104. Thus, if CMU 101 receives multiple wheel damage messages .from the same WSN 104, it can generate a wheel damage message, in such cases, CMU 1 1 may instruct WSN 104 to stop looking for wheel damage events as these will likely continue to recur and generate a barrage of messages from WSN 104 to CMU 103. In addition, the WSN 104 will have a counter to determine if it is sending wheel damage messages to the CMU 101. at a certain rate. If that rate is exceeded, the WSN 104 stops checking for wheel damage messages for a certain time period. After the time period has expired, the WSN 104 will check, to see if the rate of wheel damage messages are still too high to send to the CMU Ί0Ί .

[0062] Figure 10 is a flow chart showing the conditions under which the wheel

damage and vertical impact events are enabled or disabled. At Ϊ 02, the system is initialized and, at 1004, the system is placed in a waiting state wherein the events are disabled, as the critical speed required for event enablement has not yet been reached. Wheel damage and vertical impact events are only enabled when raiicar 103 has reached a specific critical speed. Note that the speed of raiicar 103 can be determined, by several means, one preferred way is for a message to be sent from PWG 102 to al l CMUs 101 in train consist 109. At 1006, the system checks to see if the critical speed has been reached or exceeded. The critical speed is a configurable setting of the system, typically set by each individual user, based on track and operational conditions, and is used to identify that the train is moving at a speed when such data is relevant. If not, control .returns to 1004 where the system is again placed in a waiting state with the events disabled. If, at 1006, the critical speed has been reached or exceeded, control proceeds to 1008 where both the vertical impact and wheel damage events are enabled. Control then proceeds to 1 10, where the system is placed in a waiting state having both types of events enabled. At 5012, if a vertical impact event has been detected, control proceeds to 1 14 where the system reports the vertical impact. At 1016, the system checks to see i f a wheel damage event has been detected and, if so, reports the wheel damage at 1018. In any event, control then proceeds to 1020, where the system checks to see if the raiicar 1.03 is still at the critical speed necessary for the enablement of events. If it is, the system proceeds back to 1010 where the system is pl ced in a waiting state with events enabled. If the speed of raiicar 103 has fallen below the critical speed, control proceeds to 1022 where both the vertical impact and wheel damage events are disabled, and then to 1 04 where the system is placed in a waiting state with events disabled. The proceeding acceleration events are ail events which are detected, by the variety of WSN 104 which is attached to the wheel rol ler bearing fitting 1 1 J on raiicar 103, The following events are all generated by the variet of WSN 104 which is attached to the body of rai icar 103. [0064] Longitudinal Impact -- A longitudinal impact occurs when an acceleration is detected along the length of railcar 103, and is regarded as a medium priority type of event. When a longitudinal impact message is received from a WSN 104, the CMU 101 starts a timer during which it looks for other longitudinal impact events from other WSNs 104. Longitudinal impact events are likely to occur, for example, during the coupling process and when the train consist 109 staits and stops. CMU 101 may coordinate with other C Us 101 on other railcars 103 to determine i f longitudinal impact events which are generated on each railcar 103 originate from the same physical event.

[0065] Figure 7 is a flow chart showing the conditions under which longitudinal

events are enabled. At 700, the system is initialized and at 702 the longitudinal events are enabled. The control then proceeds to 704 where the system is placed in a wait state with the events enabled and enters a detection loop. At 706 the system determines whether a longitudinal impact has been occurred and, if not, returns to 704 where the system again enters the wait state. At 706, if a longitudinal impact has been detected, control transfers to 708 where the system generates and reports a message regarding the impact. Control then returns to 704 where the system again enters the wait state.

[0066] Vertical Extreme Vehicle Dynamics - A vertical extreme vehicle dynamics event occurs when an acceleration is detected in the vertical direction of railcar 103, and is regarded as a medium priority type of e vent. An event is detected by a peak acceleration threshold being exceeded by an acceleration along the vertical axis. When a vertical extreme vehicle dynamics message is received from a WSN 104, the CMU 101 starts a timer during which it looks for other vertical extreme vehicle dynamics events from other WSNs 104. Vertical extreme vehicle dynamics events are likely to occur, for example, from a subsidence in the track or change in track modulus at a bridge abutment. CMU 101 may coordinate with other CMUs 101 on other railcars 103 to determine if vertical extreme vehicle dynamics events which are generated on each railcar 103 originate from the same physical event. [0067] Lateral Extreme Vehicle Dynamics- A lateral extreme vehicle dynamics event occurs when an acceleration is detected in the lateral, or cross line, direction of raiicar 103, and is regarded as a medium priority type of event. An event is detected by a peak acceleration threshold being exceeded by an acceleration along the lateral axis. When a lateral extreme vehicle dynamics message is received from a WSN 104, the CMU 101 starts a timer during which it looks for other lateral extreme vehicle dynamics events from other WS^'Ns 104. Lateral extreme vehicle dynamics events are likely to occur, for example, from a subsidence in the track or change in track modulus at a bridge abutment. CMU 101 may coordinate with other CMUs 1 1 on other railcars 103 to determine if lateral extreme vehicle dynamics events which are generated on each raiicar 103 originate from the same physical event.

[0068] Vertical Hunting - Vertical hunting is a condition that can last a long time with certain dynamic conditions such as track corrugation. The WSN 104s located on each end of the raiicar 103 body are commanded to periodically check for vertical hunting simultaneously, which allows a phase comparison of the readings from each WS 104. When CMU 101 receives a vertical hunting message, a vertical hunting processing timer is started and CMU 101 waits to see if another WSN 104 has reported a vertical hunting event d uring a predetermined time interval. If multiple events are received within the time interval. CMU 101 examines the messages received and if the data indicates similar periodic oscillations at each end of the raiicar 103, then the phase relationship between events occurring at each end of the raiicar 1 3 is determined. For an in phase oscillation, the CMU 101 generates a raiicar "body bounce" event. When the data indicates out of phase oscillation, CMU 101 generates a raiicar "body pitch" event. In both cases the vertical hunting message is reported by CMU 101 ,

[0069] Lateral Hunting ··· Lateral unting is a condition that can last a long time with certain dynamic conditions. Factors that contribute to lateral hunting include: high center of gravity raiiears 103, worn trucks (bogies), and worn tangent track. The lateral huntina event detection works in a fashion similar to the detection of the vertical hunting events. When CMU 101 recei ves a lateral hunting event from one of the WSNs 104s on one end of the railcar 103 (e.g., the front end), a tinier is started and, if another event is received from another WS 104 on the other end of the same railcar (e.g., the back end) withi a predetermined period of time then the events are compared for their phase relationship. If the data indicates an out of phase oscillation, then a "body yaw" event is generated. However, if the data indicates an in phase

oscillation a "body roll" event is generated. In either case, a lateral hunting message is reported by CMU 1 i .

Figure 8 is a flow chart showing the enabling, disabling, and reporting of vertical and lateral hunting events. At 800, the system is initialized and, at 802, the system is placed in a waiting state with the events disabled. Events, in this case, are disabled when the speed of railcar 103 is below a critical speed. Vertical and lateral hunting events are only enabled when the speed of railcar 103 exceeds the critical speed. At 804, the system checks to see whether critical speed has been exceeded and, if not, returns to the system waiting state in 802. However, if the critical speed has been exceeded, at 806., the vertical and lateral hunting events are enabled and, at 808, the system enters a loop wherein the hunting data is sent to CMU 101 and then analyzed to see if a hunting event has occurred. At 810, CMU 101 analyzes the data and, at 812, determines whether or not a bruiting event has been detected. If a hunting event has been detected, control proceeds to 814 where the event is reported. If no hunting event has been detected in 812, control proceeds directly to 816 where the system again checks to see if the speed of railcar 103 is over the critical speed, if the speed of railcar 103 is still high enough for hunting events to be enabled, control returns to 808 and the system again enters the loop. If the speed of railcar 1.03 has fallen below the critical speed, control proceeds to 818, where the hunting events are disabled, and the to 802, where the system is placed in the waiting state with events disabled. With reference to Figs. 4 and 12, a general implementation model of the analysis system of a WSN J 04 is now described. As depicted in the preferred embodi ment, the analyzed signal (what is not filtered out by the mechanical filter 410 or potting material), originates with aceeleronieter hardware 404 and is passed to one or more sensor sections 1.202, 1208 or 1214. These sensor sections select the data to be analyzed using a digital data filter 1204, 1210 or 121 , and passes this data on to a feature detector 1206. 1212 or 12.18. Data selection can be based on, for example, direction (e.g. vertical or longitudinal components), frequency (e.g. high-frequency clangs or low frequency rocking), overall magnitude (combination of 2 or 3 directional components) or other variations of the collected data.

The feature detectors may use a variety of techniques to determine if specific features are present. Features may include but are not limited to, pulse peaks or duration, root mean square (RMS) level of magnitude values, or presence or lack of specific frequency components. Once a feature is detected, a message is passed on to message module 1220 to be delivered to the C U 101. The sensor section may also perform periodic tests to determine if the feature is still present, if it is, the section can also determine if continued messages should be sent or if a message should be sent only when the feature is no longer present.

One possible implementation of the analysis system of Fig. 12 is shown in Figure 13. Here, accelerometer 404 passes data on to three sensor sections. The first section 1302 selects data from the longitudinal di rection do wn the length of the railcar 103 and uses Longitudinal Section 1304 to extract longitudinal impact data. Longitudinal impacts are detected in Impact Detector 1306 when the peak val ue of the

longitudinal data exceeds a longitudinal impact threshold. The second section 1308 selects data from the lateral direction across the railcar 103 and uses Lateral Section 131.0 to extract lateral oscillation data. Lateral oscillations are detected in Vehicle Dynamics Detector 1 1 when the RMS value of the oscillations exceeds a lateral oscillation threshold. The third section 1314 selects data from the vertical direction and uses Vertical Section 1316 to extract vertical oscillation data. Vertical oscillations are detected in Vehicle Dynamics Detector 13 18 when the RMS value of the oscillations exceeds vertical oscillation threshold. Each of these sensor sections sends its messages on to message module 1220 which, in torn, passes these messages on to the CMU 10 ! .

[0074] Another possible implementation of the analysis system is shown in Figure .14. Here,

acce^'lerometer 404 passes data on to three sensor sections. The first section 1402 looks at data from the vertical direction and uses Vertical Derailment Filter 1404 to extract the characteristic frequencies of a derailment. Derailment events are detected in Derailment RMS Detector 1406 when the R.MS value of the filtered data exceeds a derailment threshold. The second section 1408 also selects data from the vertical direction, but uses Vertical Wheel Damage Filter 1 1 to extract the characteristic frequencies of wheel damage. Wheel damage is detected in Wheel Damage RM S Detector 1412 when the RMS value of the filtered dat exceeds a wheel damage threshold. The third section 141 also selects data from the vertical direction and uses Vertical impact Filter 1416 to extract vertical impact data. Vertical impacts are detected in Vertical Impact Peak Detector 141 8 when the peak value of the filtered data exceeds a vertical impact threshold. Each of these sensor sections sends its messages on to message module 1 20 which, in turn, passes these messages on to the CMU 101.

[0075] When a derailment occurs, the wheels of one or more axles fall off the rails and run

along the track bed. The rough nature of the track bed causes the derailed wheels to experience high-energy vertical accelerations for the duration of the derailment. In a preferred embodiment, a derailment is readily identified by calculating the RMS value of a series of consecutive vertical acceleration measurements and compari ng the result with a threshold. If the CMU sees such dat from the WSNs on both sides of the same axle, this could indicate a derailment. On the other hand, acceleration data from a single WS^'N regarding just one wheel processed through, sensor section 1408 is more likely to indicate a damaged wheel.

[0076] CMU 101 also collects temperature data from each WSN 104. The

collection of temperature data from each WSN 104 must be synchronized to avoid conflicts between WSNs 104 while transmitting the data to CMU 101 , and to allow timely comparison and coordination of the temperature data from the readings from WSNs 104. This is achieved by storing the

temperature data in a rotating buffer organized as one data set composing one reading from each WSN 104 temperature sensor 406. In the preferred embodiment, each WSN 104 samples its temperature sensors 406 once per minute, four consecutive samples are averaged once e e ' 4 minutes. The WSM J 04 then sends a message containing 8 consecutive sample averages to the CMU 101 once every 32 minutes. CMU 101 keeps twenty samples in its rotating buffer for each temperature sensor 406, however, one of skill in the an would realize thai other sampling intervals and buffer sizes could be used, it should be noted that WSNs 104 may have more than one temperature sensor 406. After each temperature message is recei ved, the oldest set of data in the rotating buffer is discarded. When the data set is complete, the temperature data is examined for any significant temperature trends or events and then cleared so that the temperature data is used only once. As newer temperature messages m'e received, the buffer wraps around so that new data overwrites the oldest time slots, it should be noted that the WSNs 104 do not analyze the temperature data for specific events, but instead merely report it to the CMU 101. The CM U 101 examines the temperature data for trends and reports when certain thresholds have been detected, it should be noted that the temperature analysis is only performed when the train consist .109 is moving and is disabled whe the train consist 109 is stationary. Therefore. WSNs 104 will not collect or report temperature data unless the train consist

109 is movina.

The following table is a l isting of the alarms and warnings generated by the statistical analysis performed by the CMU 101 on the temperature data.

Peak Analysis Greater than x% of the temperature

leanings in one n rysis. biansn » xi-ee

the absolute temperature analysis

threshold Ambient Greater than y% of temperature readings Analysis in the analysis statistics exceed the

above ambient temperature analysis

threshold

Rate Analysis z% of the operational time exhibits a

temperature rise exceeding the

temperature rate analysis threshold

The variables x_; y and z, in the above table indicate that these numbers are configurable depending on the preferences of the user or customer. As an example of a Peak Analysis operation, if x (as configured by the user, e.g., 20, 25 or 30) percentage of temperature readings on a bearing over a period of time exceed the absolute temperature analysis threshold, an alarm or warning may be sent. As an example of the usefulness of carrying out the different analyses, it is possible that the Ambient Analysis on a hot bearing, if the train is running in very hot weather conditions, might not indicate a problem when in fact there might be one, while the Peak Analysis which looks just at the bearing temperature will provide a warning or alarm. On the other hand, in very cold weather, the Peak Analysis may not indicate a problem with a hot bearing due to the cold weather cooling down, the bearing, while the Ambient Analysis would. An example of Rate Analysis - when the railear is not moving, a bad bearing will be at ambient temperature, but once the railear starts moving, the bad bearing may heat up quicker than the other bearings on the railear. and iherefore will have a higher percentage of operational time it exceeds the threshold temperature rate. As with acceleration events, WSNs 104 are also able to check for

temperature events and report when the measured temperature exceeds certain thresholds. The table below lists these temperature-related alarms and events that can be provided immediately: Peak Alarm Absolute temperature alarm threshold is

exceeded

Peak Warning Absolute temperature warning threshold

is exceeded

Ambient Temperature above ambient alarm

Alarm threshold, is exceeded

Ambient Temperature above ambient warning

Warning threshold, is exceeded

Differentia! Temperature difference alarm threshold

Alarm is exceeded between bearings on the

same axle

The first four Alarms and Warnings in the above table are based on data preferably collected by individual WS^'Ns and do not require any analysis other than the exceeding of a threshold and thus can be initiated by the WSN that collected the data. The last one, the Differential Alarm, requires data from at least two WSHs located on bearing fittings on opposite sides of an axle, and therefore the analysis and Alarm will preferably be carried out by the CMU. Figure 11 is a flow chart showing the processing of e vents related to the measurement of temperatures of the wheel bearings of railcar 103. At 1 100, the system is initialized and, at 1102, the system enters a waiting state wherein the temper ture monitoring events are disabled. Events are disabled, in this case, when the railcar 103 is not moving. At .1 104, the system checks to see if the railcar is moving and, if not, returns to 1 02 where it again enters the wai ting state with events disabled, if the railcar is moving, control proceeds to 1 106 where the temperature nionitoring events are enabled. The system then proceeds to 1 108 where it enters a loop wherein events are checked. Control proceeds to 1 1 10 where the system again checks to see make sure the raiicar .103 is moving. If the raiicar 103 is not moving, control, proceeds to 1 1 12 where the temperature monitoring events are disabled and then back to 1 .102 where the system is placed in a waiting state with events disabled. If. at i 1 10, the raiicar 103 is still moving, control proceeds to 1 i 14 where the system checks to see if a set of temperature measurements are available. If not, control returns to 1 108 where the system is in the waiting state with events enabled, if a set of temperature measurements is available in Π 14, control proceeds to 1 1 1.6 wherein the WSN 1.04 transmits the set of temperature measurements to CMtJ 101. At 1 1 18, CMU 101 performs an analysis of the temperature measurements, including all those in the rotating buffer and, in at 1 120, decides if a temperature threshold has been exceeded. If not, control returns to .1 .108 where the system is in a waiting state with events enabled. If a temperature threshold has been exceeded, the system reports the temperature measurements at 1 122 and then returns to 1 108 where it is again in the system waiting state with events enabled. CMU 101 also detects long terra trends and keeps data regarding trends in the analysis of bearing condition. The following statistics are collected, for every bearing being monitored by a WSN 104 in the raikar-based mesh network; 105:

Total number of valid temperature readings;

Sum of valid temperature readings;

Sum of valid temperature readings squared; . Number of temperature readings greater than the absolu te temperature threshold;

Number of temperaiure readings greater than the above ambient temperature threshold; and , Number of temperature change rates greater than the heating rate threshold. [0081 ] The bearing temperature statistics are accumulated on a dail basis in a rotating buffer that can bold thirty-two sets of data, thus allowing trend analysis over a thirty-day period. The DCEP engine controls the time that statistics are accumulated as a new set of statistics has begun and the oldest is discarded. Normally the event engine is configured to generate an analysis

once per day.

[0082] The collected statistics may be used to calculate information that indicates

hearing wear trends. In a preferred embodiment, a CMU 101 provides a report upon request of the following quantities for every wheel bearing; a. Average bearing temperature; b. Variance of bearing temperature; c. Percentage of bearing temperature readings that exceed an absolute threshold; d. Percentage of bearing temperature readings above ambient that exceed a threshold; and e. Percentage of measurements that the rate of increase of bearing temperature exceeds a threshold.

[0083] A train-based mesh network is shown generally as reference -number 107 in

Figs. 2 and 3. Train-based mesh network 107 is overlaid on a train consist

109 and includes a PWG 102 installed on a host or control point such as a locomotive 108, or on another asset with access to a power source, and one or more CMUs 10 L each belonaina to the train-based mesh network 107 and also to their respective raiicar-based mesh networks 105, if one or more WSNs 104 are present, or respective raiicar-based mesh networks or network

118 for ailcars 103 with a CMU 101 but no WSNs 04 (see Fig. 2). (Note that there ca also be railcars 103 in train consist 1.09 without a CMU 101 thereon, as shown by reference number 1 19 in Figure 2), Thus, here, CMUs 101 can belong to two mesh networks, railear-based mesh network 105 (if railcar 103 is fitted with one or more W Ns 104) and train-based mesh network 107. Each CMU 101 is also optionally managing its respective railcar-based mesh network 105. Fig. 3 shows a case wherein the train-based mesh network 107 consists of three CMUs 101 , two of which are part of railcar-based mesh networks 105, and one located on a raiicar 103 (reference number 118) wherein no WSNs .104 are connected.

[0084] Train-based mesh network. 107 uses an overlay mesh network to support low- power bi-directional communication throughout train consist 109 and with PWG 102 installed on locomotive 108. The overlaid train-based mesh network 107 is composed of wireless transceivers embedded in the CMU 101 on each raiicar 103. Each CMU 101 is capable of initiating a message on the train-based mesh network 107 or relaying a message from or to another CMU 101. The overlay train-based mesh network 107 is created independently of, and operates independently of the railcar-based mesh networks 105 created by each raiicar 103 in the train consist 109.

[0085] A bi-directional PWG 102 manages the train-based mesh network 107 and communicates alerts from the CMUs 101 installed on individual, railcars 1.03 to the host or control point, such as the locomotive 1 8, wherein the alerts or event reports ma be acted upon via human intervention, or by an aittomaied system. Locomotive 108 may include a user interface for receiving and displaying alert messages generated by train-based mesh network 107 or any of the individual railcar-based mesh networks 105. Bi-directional P WG 102 is capable of receiving multiple alerts or events from CMUs 101 on indi vidual railcars 103 and can draw inferences about specific aspects of the performance of train consist 109,

[0086] Bi-directional PWG 10:2 is also capable of exchanging information with a external remote railroad operations center 120, data system or other train management system. This communication path is shown in Fig, 3 as reference number 122, and can include cellular, LAN, Wi-Fi, Bluetooth, satellite, or other means of communications. Phis link can be used to send alerts off-train consist. 109 when the train consist 109 is in operation. it is appreciaied thai described above are novel systems, devices and methods. If is also understood that the invention is not limited to the embodiments and illustrations described above, and inchides the full scope provided by the claims appended hereto.

* !{: ¾s * !f:

Claims

We claim:

1. A system for detecting operational anomalies on a train consist or railcar comprising:

a) one or more communication management units mounted on one or more raiicars; b) one or more sensors located on said one or more raiicars for sensing an operational parameter of said one or more raiicars, said sensors being in

communication with said one or more communication management units; and c) wherein said communication management units perform the functions of;

i) collecting data regarding said one or more railcar operational parameters; ii) analyzing said collected data for trends or events indicative of an anomalous operational condition; and

in) communicating a message to a remote receiver when said trend or event is detected,

2 , The system of claim 1 further comprising one or more wireless sensor nodes in communication with one of said communication management units, sai d one or more sensors forming pail of said one or more wireless sensor nodes.

3, The system of claim 2 wherein each of said wireless sensor nodes performs the functions of:

a) collecting data from one or more sensors;

b) comparing sa id data against one or more rides; and

c) sending a message to said communication management unit when at least one of said rules is satisfied.

4. The system of claim 2 wherein each of said wireless sensor nodes performs the functions of.

a) collecting data from one or more sensors; and

b) periodically sending said collected data to said communication management unit.

5. The sy stem of claim 3 wherein said one or more rules are numerical thresholds which, when exceeded by said collected data, cause an alert, message to be sent to said communication management unit.

6. The system of claim 5 wherein said data is acceleration data .

7. The system of claim 5 wherein said data is temperature data .

8. The system of claim 5 wherein said communication management, unit, upon receiving an alert message rom one of said wireless sensor nodes, performs the functions of:

a) waiting to see if similar messages are received from one or more other wireless sensor nodes within a predetermined period of time and concluding that an actual event has occurred if said similar messages are received; and

b) communicati g a message reporting the occurrence of said actual event to a remote receiver,

9. The system of claim 4 wherein said communication management an.it, upon receiving said periodically sent data, performs the functions of:

a) storing said data in a data store;

b) analyzing said stored data for trends; and

c) generating a report when trends of interest are defected.

.

10. The system of claim 8 wherein said wireless sensor node is mounted on the wheel bearing fitting of a railcar and wherein said data is analyzed to see if acceleration thresholds representing one or more of the fol lowing have been exceeded: wheel damage, vertical impacts or derailment.

11 . The system of claim 8 wherein said wireless sensor node is mounted on the body of a railcar and further wherein said daia is analyzed to see i acceleration thresholds representing one or more of the following have been exceeded: vertical hunting. lateral hunting, vertical extreme vehicle dynamics, lateral extreme vehicle dynamics, or longitudinal impacts.

12. The system of claim 7 wherein said wireless sensor node is mounted on the wheel bearing fitting of a raiicar and wherein said data is analyzed to see if a temperature threshold representing absolute temperature or temperature above ambient have been exceeded.

13. The system of claim 8 wherein said communication management unit confirms that a derailment event has occurred when derail messages have been received from a plurality of wireless sensors nodes within said predetermined period of time.

14. The system of claim S wherein said communication management unit confirms that vertical hunting is occurring when vertical h anting messages are received from wireless sensor nodes mounted on opposite ends of a raiicar within a predetermined period of time.

15. The system of claim 14 wherein said communicatio management unit determines that a body bounce event has occurred when messages from said wireless sensor nodes indicate that vertical hunting messages received from said, wireless sensor nodes indicate in phase accelerations were detected.

16. The system of claim 14 wherein said communication management unit, determines that a body pitch event has occurred when messages from said wireless sensor nodes indicate that vertical hunting messages received from said wireless sensor nodes indicate out of phase accelerations were detected.

17. The system of claim 8 wherein said communication, management unit confirms that a lateral extreme vehicle dynamic event has occurred when lateral extreme vehicle dynamic messages have been received from a plurality of wireless sensors nodes within said predetermined period of time.

18. The system of claim 8 wherein said communication management unit confirms that a vertical extreme vehicle dynamic event has occurred when vertical extreme vehicle dynamic messages have been received from a plurality of wireless sensors nodes within said predetermined period of time.

19. The system of claim 8 wherein said communication management unit confirms that lateral hunting is occurring when lateral hunting messages are received from wireless sensor nodes mounted on opposi te ends of a raiicar within a predetermined period of time.

20. The sy stem of clai m 19 wherein said communica tion management unit determines that a body yaw event has occurred when -messages from said wireless sensor nodes indicate that lateral hunting messages received form said wireless sensor nodes indicate out of phase accelerations were detected.

21. The sy stem of claim 19 wherein sai d communication management unit determines that a body roll event has occurred when messages from said wireless sensor nodes indicate that lateral hunting messages received form said wireless sensor nodes indicate in phase accelerations were detected.

22. The system of claim 7 wherein said wireless sensor node is mounted on the wheel bearing fitting of a raiicar and wherein said data is analyzed to determine if a temperature threshold representing absolute temperature or temperature above ambient have been exceeded.

23. The system of claim 4 wherein said da ta is temperature data.

24. The sy stem of claim 3 wherein said wireless sensor nodes are mounted on wheel bearing fittings of a raiicar on opposite sides of a same axle, and wherem said communication management unit generates a differential temperature alert when temperatures reported by said wireless sensor nodes on said opposite sides of said axle exceed a differential tlireshoid.

25. The system of claim 23 wherein said communication management unit generates an alert if greater than a certain percentage of the temperature readings received exceed an absolute temperature threshold or an above ambient temperature threshold.

26. The system of claim 23 wherein said communication management unit generates an alert if greater than a certain percentage of temperature readings indicate a temperature rise rate exceeding a certain threshold.

27. The system of claim 3 wherein said communication management unit can instruct each wireless sensor node to enable or disable the checking of individual rules by sending a message to said wireless sensor node.

28. The system of claim 4 wherein said communication managemen t unit can instruct each wireless sensor node to enable or disable the periodic sending of data by sending a. message to said wireless sensor node.

29. The system of claim 3 wherein each communication management unit in communication with one or more wireless sensor nodes form a raikar-based mesh network comprising said communication management unit and said wireless sensor nodes, said raikar-based mesh network being controlled by said communication management u t.

30. The system of claim 29 wherein said communication management unit includes wireless sensor nodes from other raikars in its railcar-based mesh network.

31. The system of claim I further comprising a powered wireless gateway controlling a train-based network that includes said powered wireless gateway and a plurality of said communication management units.

32. The system of claim 31 wherein said powered wireless gateway serves as said remote receiver.

33. The system of claim 1 wherein said remote receiver is located ofP-train.

34. The system of claim 33 wherein said communication management nnit communicates with said off-train remote receiver via a communication means comprising one of cellular, satellite, WiFi and Bluetooth.

35. A method for detecting operational anomalies on a train consist or raikar comprising the steps of:

a) collecting data regarding said one or more railcar operational parameters;

b) analyzing said collected data for trends or events indicati e of an. anomalous operational condition; and

c) communicating a message to a remote receiver when said trend o event is detected.

36. The method of claim 35 wherein steps (a) - (c) are performed by a

communication management unit located on a railcar in said train consist.

37. The method of claim 36 wherein said data is collected from one or more wireless sensor nodes on said railcar, said wireless sensor nodes being in communication with said communicatio management unit.

38. The method of claim 37 wherein said communication management unit and said one or more wireless sensor nodes form a railear-based. mesh network.

39. The method of claim 37 wherein said wi reless sensor nodes each perform the functions of:

a) collecting data from one or more sensors; h) comparing said data aaainst one or more rules; and

c) sending a message to said communication management unit when at least one of said rules is satisfied.

40. The method of claim 39 wherein said one or more rul es causes data coll ected from some sensors to be penodicaliy sent to said communication management unit.

41. The method of claim 39 wherein said data includes one or more of the following: acceleration data and temperature data.

42. The method of claim 37 wherein sai d communication management unit

coordinates messages from two or more wireless sensor nodes to confirm that an event has occurred.

43. The method of claim 42 wherein acceleration, events are selected from a group consisting of wheel damage, vertical impact, derailment, vertical hunting, lateral hunting and longitudinal impact.

44. The method of claim 42 wherein temperature events include one or more of the following absolute temperature alarm, above ambient temperature alarm, differential temperature alarm, peak analysis alarm, ambient analysis alarm and rate analysis alarm.

45. The method of claim 36 wherein all communication management units on said train consist are configured in a train-based wireless mesh network controlled by a powered wireless gateway,

46. The method of claim 35 wherein said remote recei ver is off-tram.

47. The method of claim 45 wherein said remote receiver is said powered wireless gateway.

48. The system of claim 1 wherein at least one of said communication management units includes at least one of said sensors.

49. The system of claim 3 wherein one of said wireless sensor nodes comprises: a) a protective housing:

b) said one or more sensors mounted within said protective housing;

c) a communication capability, for communicating with said communication management unit; and

d) a microprocessor, executing firmware to control the operation of said wireless sensor node.

50. The system of claim 49 wherein said one or more sensors includes a sensor to measure accelerations and wherein said wireless sensor node is toed to detect certai types of accelerations.

51. The system of claim 50 further comprising a mechanical filter which includes a resilient material selected to filter out undesirable accelerations, said mechanical filter disposed to remove said undesirable accelerations before said undesirable

accelerations reach said acceierometer,

52. The system of claim 50 wherein said wireless sensor node further comprises potting material dispose within said housing, said potting material used to tune said wireless sensor node by absorbing undesirable accelerations,

53. The system of claim 49 wherein said firmware includes one or more software filters used to isolat certain types of accelerations.

54. The system of claim 49 wherein said firmware performs the functions of:

a) reading data from said one or more sensors;

b) comparing said data against a set. of rules for reporting alerts or events; and c) communicating an alert or event to said communication, management unit wliew said data meets one or more of said rules.

55. The system of claim 49 wherein said firmware implements an analysis system for detecting events, said analysis system comprising:

a) one or more sensor sections, each of said sensor sections having;

i) a filter, for isolating particular accelerations of interest from data read from one or more acceleration detectors; and

ii) a feature detector, for detecting particular features of interest from said filtered data,

56. A system for detecting operational anomalies on a train consist or railcar

comprising:

a) a train-based mesh network comprising a powered wireless gateway and one or more communication management units located on one or more raiicars in said train consist;

b) one or more raiicar-based mesh networks comprising said one or more

communication management units, each arranged in a. mesh network: configuration with one or more wireless sensor nodes;

c) a distributed complex event processing engine distributed across said wireless sensor nodes, said communication management units and said powered wireless gateway, said distributed complex event processing engine detecting anomalous operating conditions on said train consist via data gathered by sensors controlled by said wireless sensor nodes and propagated upwards through said system.

57. A wireless sensor node configured for attachment to a railcar, comprising:

a. a protective housing;

b. a power source;

c. an acceierometer;

d. electrical circuitry for wireless communications and to control the operation of the wireless sensor node, and e. said electrical circuitry includes a microprocessor capable of executing firmware with one or more software filters used to isolate certain types of

accelerations.

58. The wireless sensor node of claim 57 further comprising a potting material within said housing in which said accelerometer is embedded, said potting material being selected to filter out undesirable accelerations from said railcar.

59. The wireless sensor node of claim 57 further comprising a mechanical filter made of a resilient material selected to filter out undesirable accelerations, and which is positioned to filter out the imdesirable accelerations before said accelerations are detected by said accelerometer.

60. A system for detect ing operational anomalies on a railcar that is part of a train consist comprising:

a. at least one communication management unit (CMU) mounted o the train consist;

b. at least two sensors located on the railcar for sensing operational parameters of the railcar, said sensors being in communication with said CMU^';

c. wherein said CMU performs the following functions:

i) receiving data from said sensors;

ii) drawing inferences from the data received from at least two of the sensors regarding the performance of the railcar; and

Hi) communicating a message to a remote receiver when an anomaly is detected.

61. The system of claim 60 wherein said sensors comprise accelerometers positioned at different locations of the railcar, and wherein said step of drawing inferences comprises the comparison of data from two or more of said accelerometers.

62. The system of claim 60 wherem said sensors comprise temperature sensors positioned at different locations of the raiicar, and wherein said step of drawing inferences comprises the comparison of data from two or more said temperature sensors.

63. The system of claim 61 wherem said acceleroraeters are positioned on the raiicar to provide data for carrying out one or more of the following functions:

i) compare accelerations from one raiicar wheel with that of another raiicar wheel on the same axle hut opposite side of the raiicar,

ii) compare accelerations from one raiicar wheel with that of at least one other wheel on the same side of said raiicar, and

iii) compare accelerations from one raiicar wheel with that of at least one other raiicar wheel on the same side of said one raiicar wheel and which other wheel is on another raiicar of the same train consist.

64. The system of claim 61 wherei said accelerometers are positioned on the raiicar to pro vide data for carrying out one or more of the following functions:

i) compare accelerations from front and back ends of said raiicar,

ii) compare accelerations from any two locations on the raiicar, and

iii) compare accelerations from one raiicar with those of another in the same train consist.

65. The system of claim 62 wherem said temperature sensors are positioned on the raiicar to provide data for comparing temperature data from one raiicar wheel bearing wit that of another raiicar wheel bearing on the same axle but on an opposite side of the raiicar.