IES86224Y1 - A rail train diagnostics system - Google Patents

Abstract

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 charmel 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 charmel 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 charmel.

Description

Introduction A Rail Train Diagnostics System” Siéfidéfi The invention relates to monitoring of passenger or goods rail trains.

There is an ever-increasing need for monitoring systems on trains due to the increasing schedule frequency, and more rigorous requirements for punctuality and safety.

Various approaches have been described in the art for transmitting monitoring data to a static host system.

DE10319904 (Siemens) describes on-board mobile radio equipment connected directly to a communications computer.

US2010260094 (Siemens) describes an approach to avoiding hand-offs for mobile communication for safety-critical applications.

In an approach described in EP22073781 (Siemens), access points have transceivers communicating with a mobile node in a train. techniques, and WO2009030659 (Siemens) describes dynamic address management WO2008015148 (Siemens) describes balancing of load across secure and non-secure computers.

Other documents which describe approaches to train maintenance or management information communication are: — CN20112000553 (CSR), — CN201046769 (Z. Chen), — CN 101574975 (Beijing Liujie Tech.), — V CN201287714 (Beijing Gaotie Comm. Tech.), and — JP200632755l (TMPKK).

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

Sumrnfl of the Invention According 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 fiom 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: 7* -1 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.

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 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 embodimerit, the control unit is adapted to combine new train sensor data with previously- received 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 detennine 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.

Inuone embodiment, the seiver is adapted to perform analysis of the backfill data in any one of a pliitralityi 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.

Preferably, 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.

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 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 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 having an engine.

In one embodiment, the server is adapted to compare diagnostics data from a speed sensor with derived speed determined fi'om 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.

Preferably, 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 of the 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 charmels for reception by the server 3. These transmissions include at least a live data channel and also a back-fill data charmel for data not successfully transmitted in real time.

The communications gateway ll communicates locally with the on-train communications module 12, in this embodiment including a 3G or GPRS cellular modem for data transfer. _ 5 _ 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 fiom the on- 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 - due to the presence of auto-shutdown systems on trains for fuel saving, the local data storage unit 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-Ethernet converters 33 linked with on-board train systems 34; and — direct Ethernet links 35 to some of the on-board train systems 34.

The control unit 2 interfaces with the 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 RS232 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-EthernetTM converter may be utilised to convert the serial link to Ethernet”. In this case, the control unit 2 interfaces with the device over EthernetTM using Virtual QOM drivers installed on the control unit’s data interfaces 13.

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 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 3 0.

As shown in Fig. 4 the server 3 has the following software function applications: 50, data management; , 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 fi‘ont-end display of the data for application users, with computers or mobile devices. In addition, the user application component 51 provides - 3 _ alerts and notifications, 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 _ 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 34. This data contains diagnostic information related to the source system that is being monitored and contains the current reading of each of the 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 GPS- starnped 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 of the 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., RPM, fuel usage, and so on) from each engine on the train at the same point in time, it is possible to identify an individual engine whose operating characteristics deviate from the other engines un_der the same operating conditions (acceleration, load, etc) and as such may require maintenance.

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 A — data for defect rectification work orders for rectification by a maintenance team, and — analysis of energy or filel 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 - 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 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 (CRCl6 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 (N ackl) 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 and 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 COITBCL 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 charmels 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 _ 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 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 NACKI, 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 back-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 the on-train systems. Whilst the message is disregarded by the shore- based 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. - 13 _ 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 from 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 10s to l80s.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 from 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 fi'om 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 processed by. the control. unit 2. - .3 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. _ 14 - 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 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 _ 15 _ 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 charmel 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 the signal has a high value. If a rule condition were to state that the minimum value of the channel were to be ‘I ’, in the 1-minute duration, the rule would incorrectly fire, as there would not be a reference to the fact that the charmel 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 event- based, 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: - 15 _ 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 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.

Infiastructure Analysis - Track Adhesion & Power Line The on—train system monitors train signals including: — Activation of wheel slide protection (W SP) 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 the 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 the 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. _ 17 _ Scheduled maintenance of 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 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 infiastructure.

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

Claims (1)

1. Claims 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 successfillly transmitted in the real time charmel. 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 been received when transmitted on the live channel; and wherein the wireless interface is adapted to automatically assign data to the backfill charmel 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: 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. 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 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; and wherein the control unit is adapted to combine new train sensor data with previously—received data, and to time stamp and location stamp the combined data. A train 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 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 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. 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 fi'om another on-board control unit of a train on a comparable run or of another carriage of the 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 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.