IES20130043A2 - A rail train diagnostics system - Google Patents

Abstract

A train diagnostics system has an on-board control unit (2) linked by a local area network (30) to interfaces (31,33,35) to train systems and sensors (32,34). A wireless interface (11) is provided for transmission of diagnostics data from the on-board control unit. A ground-based server (3) receives diagnostics data and processes it to generate diagnostic reports. The wireless interface transmits the diagnostics data in multiple channels, including a live data channel and a backfill data channel for data not successfully transmitted on the in real time channel. There is a separate sofTware process for each of said real time and backfill channels, and the real time channel process automatically hands over to the backfill channel process a message for which a 15 positive acknowledgement has not been received when transmitted on the live channel.

Description

The invention is directed towards providing improved collection and processing of diagnostics data from moving trains.

MT h riouu/ .in J Summary of the Invention IE1 3 Ο 04 3 -2According to the invention, there is provided a train diagnostics system comprising: an on-board control unit linked by a local area network to interfaces to train systems and sensors, a wireless interface for transmission of diagnostics data from the on-board control unit; and a ground-based server adapted to receive said diagnostics data and process it to generate diagnostic reports; wherein the wireless interface is adapted to transmit the diagnostics data in a plurality of channels, including at least: a live data channel, and a backfill data channel for data not successfully transmitted in the real time channel.

In one embodiment, the wireless interface is adapted to execute a separate software processes for each of said real time and backfill channels.

In one embodiment, the real time channel process is adapted to automatically hand over to the backfill channel process a message for which a positive acknowledgement has not been received when transmitted on the live channel.

In one embodiment, the wireless interface is adapted to automatically assign data to the backfill channel if wireless communication is not available in real time.

In one embodiment, the on-board control unit is adapted to manage transmissions on the backfill channel with repeated attempts in a non-cyclic manner, in which: a next message is sent immediately when a positive acknowledgement is received, the message is moved back to a queue if an acknowledgement is not received during a timeout period, or a negative acknowledgement is received indicating invalid data.

Preferably, the server controls the back-fill channel to abort a back-fill message is a second negative acknowledgement is received. -3IE1 3 0 04 3 In one embodiment, the wireless interface is adapted to send a heartbeat message to the server at periodic intervals.In one embodiment, the on-board control unit is adapted to maintain in memory the current state of each of a plurality of the train signals being monitored, and to compare new data is received in a signal with the current known state for each of the signals, and wherein the on-board control unit is adapted to transmit new data if the state has changed for one or more of the signals.

In one embodiment, the control unit is adapted to combine new train sensor data with previouslyreceived data, and to time stamp and location stamp the combined data.

In one embodiment, the server is adapted to raise an alert if invalid data is received, said alert indicating that there may be a fault with the on-train system or sensor being monitored.

In one embodiment, the server includes an event processing engine for maintaining a live session for each train, and for maintaining a current state for each session. Preferably, the event processing engine is adapted to monitor received signals from the on-board control unit and to determine a latest known state of each of the parameters being monitored, and to perform data processing to evaluate performance of the on-board train sensors and systems. In one embodiment, the event processing engine is adapted to maintain in memory not only the latest known state for each parameter, but also previously known states for a period of time defining a session.

In one embodiment, the event processing engine is adapted to, when a new event is received from the on-board control unit, update memory with the new parameter event values and to discard the oldest events if they are older than the defined session time.

In one embodiment, the server is adapted to perform analysis of the backfill data in any one of a plurality of configured mechanism, including: wait for a period of time after the data is received before it is analysed, to provide sufficient time for all of the backfill data to have been received before it is analysed, and run once periodically and analyse all of the backfill data received since it last ran. -4Preferably, the event processing engine is adapted to, when analyzing the backfill data, include both the data that was received live on the real time channel and also delayed data on the backfill channel, to ensure that the most complete data available from the train is included in the analysis. 5 In one embodiment, the event processing engine is adapted to perform analysis of event data over rolling windows of time.

In one embodiment, the event processing engine is adapted to assign to a channel an unknown 10 state until a first event is received, setting the channel to the state of the event received, and to leave the channel in that state until a second event is received, when the channel adopts the state of the second event.

In one embodiment, the event processing engine is adapted to apply a time window during which 15 the state of the channel may be changed.

Preferably, the server is adapted to maintain a live session for each train that is transmitting data. In one embodiment, the server is adapted to maintain a sliding window of all of the channel values over a configurable period of time, and to evaluate a value for a channel over this window of time. Preferably, the value is a derived value. In one embodiment, the derived value is an average value or a rate of change.

In one embodiment, the server is adapted to analyse received diagnostics data in a method which includes comparison of the data with data from other sources.

In one embodiment, the server is adapted to analyse diagnostics data in a method including comparing the data with equivalent data from another on-board control unit of a train on a comparable run or of another carriage of the same train and hairing an engine. in one embodiment, the server is adapted to compare diagnostics data from a speed sensor with derived speed determined from satellite positioning system data.

In one embodiment, the server is adapted to monitor engine or motor speed and to derive an indication of abnormal wheel wear leading to abnormal wheel diameter.

IE1 3 0 043 -5Preferably, the server is adapted to monitor wheelset traction motors which are powered from the same source inverter by monitoring wheelset rotation speed differences to determine if excessive strain is likely to be put on the traction motor.

Detailed Description of the Invention The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which:Fig. 1 is a diagram illustrating a diagnostics system of the invention at a high level, and Fig. 2 is a block diagram of an on-board control unit of the system; Fig. 3 shows how the control unit is linked in a train; Fig. 4 illustrates architecture of an application server ofthe system; Figs. 5 and 6 are flow diagrams for live and back-fill data transmission respectively, and Fig. 7 is a timeline diagram illustrating events and how event data is transmitted.

Referring to Fig. 1 a diagnostics system 1 of the invention comprises a control unit 2 on a train and, on ground, a server 3 with applications 4, interfaces 5 to third party applications, and a database 6.

As shown in Fig. 2, the on-board control unit 2 comprises a controller 10, a communications gateway 11, a GPS interface 12, data interfaces 13, and local data storage 14. The gateway 11 includes a wireless interface adapted to transmit diagnostics data in a plurality of channels for reception by the server 3. These transmissions include at least a live data channel and also a back-fill data channel for data not successfully transmitted in real time.

The communications gateway 11 communicates locally with the on-train communications module 12, in this embodiment including a 3G or GPRS cellular modem for data transfer. In IE1 3 0 04 3 .6_ other embodiments it may additionally or alternatively include a WiFi interface. The GPS interface 12 receives real time geographic location of the train.

The data interfaces module 13 provides a mechanism to retrieve diagnostic data from the on5 train systems.

The controller 10 receives the diagnostics data from each of the data interfaces 13 and correlates this data to provide a consolidated view of all of the train data. In addition, each record of data is stamped with the GPS position of the train (received from the GPS module in the interface 12) at that point in time.

The control unit’s local storage module 14 buffers the diagnostics data on-train. In this embodiment, this is implemented through persistent storage including a solid state drive (SSD) module. As on-train systems are typically powered on/off at frequent and unscheduled times 15 due to the presence of auto-shutdown systems on trains for fuel saving, the local data storage unit 14 maintains the data in the event of power loss.

As shown in Fig. 3 the control unit 2 is linked by an Ethernet™ LAN 30 to: - data acquisition units 31, in turn linked to sensors 32; - serial-Ethemet converters 33 linked with on-board train systems 34; and - direct Ethernet links 3 5 to some of the on-board train systems 34.

The control unit 2 interfaces with die on-train systems 34 and sensors 32 using the Ethernet LAN . The data exchange protocol over the LAN 30 is specific to the on-train equipment but in some embodiments involves the transfer of live diagnostics information over TCP or UDP The serial link (RS-232 / RS-485) 33 provides interfaces with the on-train system 34 if there is an existing serial port on the on-train system. The protocol for the data transmission over the serial link is specific to the train system. In some scenarios the R.S232 port on the on-train system 34 being monitored is located some distance from the control unit 2. This distance may exceed the distances supported by the standards. In this case, a serial-Ethemet™ converter may be utilised to convert the serial link to Ethernet™. In this case, the control unit 2 interfaces with the device over Ethernet™ using Virtual COM drivers installed on the control unit’s data interfaces 13.

IE A 3 0 04 3 -7 In many scenarios, it is desirable to monitor equipment 32 that does not provide a data interface -for diagnostics data. Examples are air pressures sensors in brake systems, battery and/or train line voltage sensors, and speed probes. In these scenarios the data acquisition unit (DAU) 31 5 may be utilised to capture the data being transmitted from the sensors or train wires, and transfer that data back to the control unit 2 over the on-train Ethernet connection 30.

The DAU 31 monitors the signal values on existing train control wires (for example, from the brake control lever in the cab), or the value of analogue signals (such as air pressures or voltages) through the use of sensors or transducers. The DAU 31 is required where individual components on the train need to be monitored directly through the use of sensors as a data interface is not available to provide diagnostics data.

The DAU 31 provides a number of inputs and supports a combination of digital or analogue inputs. It scans each of the digital or analogue inputs at a pre-defined frequency, for example every 100 ms, and reads the value of the inputs at that time. The data that is read by the DAU 31 from each of these inputs is then transmitted back to the control unit 2 over the on-train Ethernet connection 30.

As shown in Fig. 4 the server 3 has the following software function applications: 50, data management; 51, user applications; 52, telemetry service; 53, event processing engine; 54, data analysis service; 55, data storage interface to database 60 and system interfaces 56 Data Management Component 50 This manages the data processing and access across the system components in the application server.

User Application 51 The user application provides a Web application front-end display of the data for application users, with computers or mobile devices. In addition, the user application component 51 provides IE 1 3 ο ο 4 3 -8al J|£a1d3LO0fi!ltion? both within the application and also via email, of high priority faults that may occur on. a vehicle.

Telemetry Service 52 This provides the off-train part of the communications between the train control unit 2 and the server 3. It receives the data from each of the vehicles in the fleet, and is responsible for the acknowledgement and resending of the live and backfill data.

Event Processing Engine 53 The Event Processing (EP) Engine 53 analyses all of the diagnostics data from each vehicle as it is received live from each vehicle. The EP engine 53 is responsible for identifying pre-defined scenarios or conditions in the diagnostics data including data indicating that a train system has failed or is about to fail.

Data Analysis Service 54 This provides trending analysis of both the diagnostics data and also the event data, to provide: - Analysis of infrastructure issues, such as areas of low train-to-rail adhesion Analysis of faults or warnings on the fleet over a period of time. This provides indications of a common system fault across the fleet, or faults that are occurring more frequently.

Data Storage and Database 55, 60 This provides persistent storage of the diagnostics data to a relational database, for later retrieval and analysis.

System Interfaces 56 Provides system interfaces to third party systems, including: Timetabling systems for train allocation Maintenance management systems for raising defect rectification work orders.

In more detail, the interfaces 31, 33, and 35 are linked with train components or systems to retrieve live diagnostics data, including: brakes, doors, train management, engine management, safety event recorders, HVAC, passenger information system, custom sensors. The on-train -9|E1 3 0 043 control unit 2 correlates all of the data to create a consolidated live view of the status of the entire train.

The control unit 2 receives data inputs from a number of different existing train systems 32 and 5 34. This data contains diagnostic information related to the source system that is being monitored and contains the current reading of each of tlie signals from that system. When new data is received from a system 32 or 34, the control unit 2 combines this with the latest data from each of the other systems. This combined data from all of the systems is then time-stamped and GPSstamped with the location of the train when the data was read.

By combining the data in this manner, it becomes possible to analyse the performance of the train to identify potential faults by examining the operating characteristics of all of the train systems at the same point in time.

In many cases, analysis of the diagnostics data from an individual component in isolation does not provide an indication of a degradation or failure of that component. Frequently, identification of a failure of a system requires the comparison of the data from multiple systems, at the same point in time, in order for that failure, or potential failure, to be identified. For example, a speed probe is used to provide the train speed to the train management system. The speed probe may fail or become damaged, providing inaccurate speed readings, and this is not easily detected through an analysis of the train management system data. However, by correlating the speed signal data from the train management system with the GPS speed from the GPS system, a discrepancy between the two different signal sources typically indicates a problem with the inputs to the train management system.

In a second scenario, it is possible to identify on-train systems or components that are running outside of normal operating thresholds and as such may fail in the near future, through the comparison ofthe diagnostics data from other on-train systems.

It is a common configuration of a train to have the same component type fitted to each vehicle in a multiple vehicle train. For example, in a diesel multiple unit (DMU) train, each vehicle will have a separate engine fitted. An examination of the diagnostics data and running performance data from each engine in isolation will not always identify a potential failure. However, by comparing the operating characteristics (i.e., KPM, fuel usage, and so on) from each engine on IE1 3 0 043 the train at the same point in time, it is possible to identify an individual engine whose operating characteristics deviate from the other engines under the same operating conditions (acceleration, -load, etc) and as such may require maintenance.5 In a third scenario, a comparison of diagnostics data from all of the trains in a fleet may indicate a failure with a system on one of the trains in the fleet. Comparing the diagnostics data from two or more trains that are carrying out the same passenger journey on the same route may highlight one train that has significantly higher energy or fuel usage, which is indicative of a problem with the performance of that individual train.

In an electric train vehicle, it is typical that each wheelset is powered by its own traction motor, but for the traction motors all to be powered from the same source inverter. Therefore, it is essential that the wheesets rotate at the same speed, otherwise excessive strain is put on the traction motor, causing a failure of that component. Over time, wheelsets may wear at different rates, causing a size differential between the different wheelsets. In this scenario, the rotation speeds of each the wheelsets are monitored by the system and compared to identify differences in rotation speed, which may lead to a failure.

This data is then enhanced with additional external data on the off-train servers 3 from third party systems including for example a fleet allocation system, a timetabling system, and a maintenance management system, to provide an overall view of the fleet status.

The server 3 generates outputs including: live fleet status, - outputs from monitoring of fault conditions on a train and user notifications, identification of mechanical problems, such as track sections with low adhesion, problems track power supply, track ride, and - data for defect rectification work orders for rectification by a maintenance team, and - analysis of energy or fuel usage, for driver standards improvement.

The on-board control unit 2 is responsible for collecting diagnostics data from the on-train systems and transferring that data to the off-train server 3 over a remote wireless link such as GPRS, 3G, LTE or WiFi network connection. The server 3 (which may be a group of one or more hardware platforms) receives and processes the live diagnostics data from each train in the - 11 1EA 3 0 043 fleet, and manages the data repository 6 of diagnostics data received from the on-train equipment, for data and trend analysis. The third party application interfaces are to external -applications including: maintenance management systems, timetabling systems, and fleet allocation systems. The user applications provide access to a live fleet status, with live fault 5 identification, infrastructure fault analysis, energy, and fuel analysis.

The communications protocol between the on-train equipment and the off-train servers provide message acknowledgement handshaking which ensures reliable message delivery of live diagnostics data over an unreliable wireless network. There is also an ability to send a message from the off-train server to the on-train equipment to retrieve additional user-requested data from the on-train equipment.

A message comprises of a header, followed by data (where applicable), and a signature (CRC16 encryption). Message length and Message Identifier are integral parts of the header. Message length is the total length of the message (i.e. header + data + CRC). If the received message is not of the correct length, a negative acknowledgement (NacU) must be sent by the receiver. The Message length field is 16 bits, so that the total length of a message is limited to 65535 bytes. The practical limit is 65507 bytes, because of UDP arid IP overheads.

The message identifiers identify the type of the message, and thus the way to handle it. If a message with an unknown identifier is received, a negative acknowledgement (Nack2) must be sent by the receiver. This field must be checked by the receiver only if length and CRC are correct.

Two channels of communication are used for the communications protocol: - A first channel dedicated to the transmission of real-time data. Through this channel, a message is sent periodically, typically every 1 to 5 seconds, and the message captures all of the data monitored on the train during that period.

- A second channel is dedicated to the transmission of “back-fill” data. This is backlog data awaiting re-transmission, that the first channel failed to transmit.

These two channels are managed independently, by two different software processes, using two different ports of the gateway 11. This separation of live messages and back-fill messages - 12|E1 3 0 043 enables the prioritization of the live messages, and ensures that the most recent data from the train is not queued whilst cached data is transmitted to the off-train servers.

Each message sent by the on-train control unit 2 must be acknowledged by the shore-based 5 system 3. The on-board control unit 2 expects an acknowledgement within a configurable time period, typically 5 seconds.

Referring to Fig. 5 the following is the scheme for the first channel, for real-time data transmission: - If the transmitted message is positively acknowledged (ACK is received within 5 seconds), the transmission is deemed successfully completed.

If the message is negatively acknowledged with NACK1, or a 5 seconds timeout occurs, the real-time data software process hands the transmission of the message over to the back-fill data process and moves on to proceed with the transmission of the next message, packaging 5s worth of data representing the most recent events received from the on-train control unit 2.

- If the message is negatively acknowledged with NACK2, its transmission is aborted altogether. It will not be sent again by either the real-time data or the hack-fill data process.

The servers 3 respond to the on-train control unit 2 when the message is received successfully, but contains invalid data or message identifier. This is indicative of an error in the diagnostics data being received from tlie on-train systems. Whilst the message is disregarded by the shorebased server, it contains invalid data and therefore does not result in loss of data. Furthermore, the sending of a NACK2 message may be logged and escalated, as it also provides an indication that there is a fault with the on-train equipment being monitored.

Referring to Fig. 6, the scheme for backfill data transmission is illustrated. Messages that can not be transmitted by the real-time data process, due for example to a loss of 3G coverage, are stored and their handling is passed over to the backfill data process. Provided communication is possible (i.e 3G coverage established), the backfill data process attempts to clear its backlog of outstanding messages. This process is neither cyclic nor periodic: as soon as an ACK is received, the next backfill message is sent.

IE1 3 0 0A3 n If the transmitted message is positively acknowledged (Ack is received within S seconds), the transmission is deemed successfully completed. If the message is negatively acknowledged with -Nacki, or a timeout occurs, the backfill data process tries to send the same message again. If the message is negatively acknowledged with Nack2, its transmission is aborted altogether. It will not be sent again by the back-fill data process.

Heartbeat Signal A message is transferred periodically fiom the control unit 2 to the server 3, typically every S seconds, even if no new diagnostics data is received by the control unit 2. The parameter S is preferably in the range of 1 Os to 180s.This message indicates to the server 3 that the control unit 2 is active and available for communications. Furthermore, an updated GPS position of the train is transmitted in the heartbeat messages, providing the server 3 with an update on the train location.

Download Requests Download requests are created by the user in the applications 51 and transferred over the communications channel 52 to the on-train control unit 2.

A UDP message is transmitted from the server 3 to the control unit 2 with a message identifier that indicates a user request to download a diagnostic file fiom an on-train system 2. The message data contains details of which system the diagnostic file has been requested from.

The request is passed to the relevant on-train system 2 through the data interfaces and the subsequently-generated diagnostic file is transferred to the server 3 using FTP.

In addition, it may receive requests from a user application 51 for additional data downloads, which the telemetry service 52 transmits from the off-train system to the train, where it is pro cessed by the control unit 2.

Typically, the remote diagnostics data is event-based, meaning that data from a particular signal or parameter is only received when the value changes. Similarly, when there are no changes to the state of a channel, no data updates are transmitted from the train.

IE1 3 0 04 3 The control unit 2 maintains in its internal memory the current state of each of the train signals being monitored. When new data is received by the control unit 2 from one of the systems 32 or 34 on the train, a comparison is made with the current known state for each of the signals. Only if the state has changed for one or more of the signals, the new data is transmitted to the server 5 and the internal memory of the control unit 2 updated with the new value of the signal.

The server 3 maintains a live ‘session’ for each vehicle that is transmitting data. This session maintains a sliding window of all of the channel values over a configurable period of time, for example the last 1 minute period. This facilitates the ability to evaluate the value (or derived value - e.g., average, rate of change, and so on) for a channel over this window of time.

As the source data is event-based, if there are no changes in the values of the channels for a particular vehicle the most recent channel data record for a vehicle may be older than the time duration that is specified in the rule condition.

In order to facilitate the correct analysis of the channel values, the system 1 maintains the state of each channel through data interpolation, in which no new events being received indicates that a channel value has changed. Once a new event is received from the train, the associated internal state is updated with the new value.

New events that are received by the event processing engine 53 contain the latest known state of each of the signals being monitored by the on-train system 2. In order to evaluate the performance of the sensors and systems 32 and 34 being monitored over a period of time, the event processing engine 53 maintains in its internal memory not only the latest known state for each signal, but all previously known states for a period of time, known as a session.

When a new event is received from the train, the event processing engine 53 updates its internal memory with the new signal values. At this time, it may also discard the oldest events should they be older than the defined session time, or the event processing engine 53 determines that they are no longer required for evaluation of the event rules.

When a rule with configured conditions analyses data over a window of time (for example, the average value of a channel over the. time window), the rule will also check to ensure that the IE1 3 0 043 window also contains the minimum number of records that has been specified. This ensures that there are sufficient events in the time window before the rule is evaluated.

Fig, 7 outlines an example scenario for a digital channel “Forward Demanded” over a particular time window. In this example scenario, the channel is in an unknown state until Event 1 is received, setting the channel to high. The channel stays in a high state until Event 2 is received, when the channel goes low. This has a 1-minute time window (duration). The Event 2 that sets the state of the channel to low falls outside the duration window and is therefore not processed as an event when analysing the sliding window. However, the state of this channel is maintained by the event processing engine in the sliding window (as a low value), until Event 3 is received, setting the signal to a high state.

If the state were not to be maintained in the sliding window (prior to Event 3 being received), then at the point of receiving Event 3, the only value available for the channel is that ihe signal has a high value. If a rule condition were to state that the minimum value of the channel were to be ‘ 1 ’, in the 1 -minute duration, the rule would incorrectly fire, as there would not be a reference to the fact that the channel had a low state prior to Event 3 being received.

As can be seen from Fig. 7, the channel goes high at Event 3 in the sliding window duration of 1 minute. If the minimum records variable is set to three events for when the channel is in a high state, then this rule condition would not be met until Event 5 is received.

In the example scenario outlined in Fig. 7, a rule has been configured in the event processing engine 53 to evaluate a particular signal, the Forward Demanded signal, over a period of 1 minute. The plot shows the value of this signal over a time window. As the system is eventbased, it is assumed that the value of the signal remains constant until a new event is received indicating the new value of the signal.

When analyzing the diagnostics data, the event processing engine 53 separately analyses the live data received and the data that has been buffered on-train and transmitted at a later point (i.e., the backfill data). This ensures that the live data received is analysed as soon as it received and as a result faults are identified as early as possible.

The analysis of the backfill data can be configured to operate in different ways, including: - 161E1 3 0 043 The event processing engine 53 waits for a period of time (e.g., 1 hour) after the data is received before it is analysed. This provides sufficient time for all of the backfill data to -have been received before it is analysed.

The event processing engine runs once periodically (e.g., once daily) and analyses all of 5 the backfill data received since it last ran.

When analyzing the backfill data, the event processing engine 53 includes both the data that was received live and also the delayed data. This ensures that the most complete data available from the train is included in the analysis.

Infrastructure Analysis - Track Adhesion & Power Line The on-train system monitors train signals including: - Activation of wheel slide protection (WSP) equipment - Activation of wheel sanding by the driver, to increase adhesion - For electric trains, the input voltage and current (from overhead lines, or third rail systems).

Individual event data from each train in the fleet is analysed by the server 3 and aggregated across the entire fleet. The on-train control unit 2 associates a GPS position and timestamp with each event, and the data analysis service 54 then aggregates the data by time and location across the entire fleet.

The user application 51 then presents detailed information, both in a tabular view and on a geographical map, of areas on the train route where there are problems with adhesion, or line voltages. These key issues may affect train running performance, but are not attributed to faults with the on-train systems. Also, the server 3 provides a number of different inputs to maintenance management systems for the purposes of maintaining tlie fleet of trains and rectifying defects. These include: Defects or failures in an on-train component are identified, and a rectification work order can be raised automatically in a maintenance management system, to alert the depot to the failure in advance of fhe train arriving in for maintenance. This enables the depot to plan for the repair work, and ensure that the correct materials, replacement component, etc., are available for when the train arrives in the depot. -17IE1 3 Ο Ο 4 3 Scheduled maintenance cf a train is carried out based on the number of miles that the train has run, or the number of hours the engines have been running for.

In the prior art these counters can be difficult to monitor without visiting each train and taking 5 readings. This makes the scheduling of the maintenance into a depot with constrained resources difficult, as it can be hard to predict when the maintenance will be due on each train. The system accurately tracks multiple counters against each train, or indeed individual components on a train for component based maintenance. Typically this includes: - Distance run. This is accurately tracked from GPS positioning - Engine running hours. By taking an input from the engines, the engine running hours counter is incremented when the engines are running (for example when the RPM is greater than say 600).

It will be appreciated that the invention provides for comprehensive monitoring and processing of train diagnostics data. This is achieved in a robust manner despite the lack of reliability of the wireless communications infrastructure.

The invention is not limited to the embodiments described but may be varied in construction and detail.

Claims (5)

1. Claims -l·.-A train diagnostics system comprising:an on-board control unit linked by a local area network to interfaces to train systems and 5 sensors, a wireless interface for transmission of diagnostics data from the on-board control unit; and a ground-based server adapted to receive said diagnostics data and process it to generate diagnostic reports; 10 wherein the wireless interface is adapted to transmit the diagnostics data in a plurality of channels, including at least: a live data channel, and a backfill data channel for data not successfully transmitted in the real time channel.
2. 2. A train diagnostics system as claimed in claim 1, wherein the wireless interface is adapted to execute a separate software processes for each of said real time and backfill channels; and wherein the real time channel process is adapted to automatically hand over to the backfill channel process a message for which a positive acknowledgement has not 20 been received when transmitted on the live channel; and wherein the wireless interface is adapted to automatically assign data to the backfill channel if wireless communication is not available in real time; and wherein the on-board control unit is adapted to manage transmissions on the backfill channel with repeated attempts in a non-cyclic manner, in which: 25 a next message is sent immediately when a positive acknowledgement is received, the message is moved back to a queue if an acknowledgement is not received during a timeout period, or a negative acknowledgement is received indicating invalid data. 30
3. 3. A train diagnostics system as claimed in claim 2, wherein the server controls the back-fill channel to abort a back-fill message is a second negative acknowledgement is received; and wherein the wireless interface is adapted to send a heartbeat message to the server at periodic intervals; and wherein the on-board control unit is adapted to maintain in memory the current state of each of a plurality of the train signals being monitored, and IE 1 3 Ο Ο 4 3 - 19to compare new data is received in a signal with the current known state for each of the signals, and wherein the on-board control unit is adapted to transmit new data if the state -has changed for one or more of the signals; and wherein the control unit is adapted tocombine new train sensor data with previously-received data, and to time stamp and 5 location stamp the combined data.
4. 4. A frain diagnostics system as claimed in any preceding claim, wherein the server includes an event processing engine for maintaining a live session for each train, and for maintaining a current state for each session; and wherein the event processing engine is 10 adapted to monitor received signals from the on-board control unit and to determine a latest known state of each of the parameters being monitored, and to perform data processing to evaluate performance of the on-board train sensors and systems; and wherein the event processing engine is adapted to maintain in memory not only the latest known state for each parameter, but also previously known states for a period of time 15 defining a session; and wherein the event processing engine is adapted to, when a new event is received from the on-board control unit, update memory with the new parameter event values and to discard the oldest events if they are older than the defined session time. 20
5. 5. A train diagnostics system as claimed in any preceding claim, wherein the server is adapted to analyse received diagnostics data in a method which includes comparison of the data with data from other sources; and wherein the server is adapted to analyse diagnostics data in a method including comparing the data with equivalent data from another on-board control unit of a train on a comparable run or of another carriage of the 25 same train and having an engine; and wherein the server is adapted to compare diagnostics data from a speed sensor with derived speed determined from satellite positioning system data; and wherein the server is adapted to monitor engine or motor speed and to derive an indication of abnormal wheel wear leading to abnormal wheel diameter; and wherein the server is adapted to monitor wheelset traction motors which 30 are powered from the same source inverter by monitoring wheelset rotation speed differences to determine if excessive strain is likely to be put on the traction motor.