EP2765053B1

EP2765053B1 - A rail train diagnostics system

Info

Publication number: EP2765053B1
Application number: EP14154105.2A
Authority: EP
Inventors: Karl O'CONNELL; Marcus O'connell; Paul LOWRY
Original assignee: Trimble Railway Ltd
Current assignee: Trimble Technologies Ireland Ltd
Priority date: 2013-02-06
Filing date: 2014-02-06
Publication date: 2016-10-19
Anticipated expiration: 2034-02-06
Also published as: EP2765053A3; EP2765053B8; IES20130043A2; IES86224B2; EP2765053A2

Description

INTRODUCTION

Field of the Invention

The invention relates to monitoring of passenger or goods rail trains.

Prior Art Discussion

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.
EP 1535418 B1 describes a train diagnosis system with the features of the preamble of claim 1.
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.
WO2009030659 (Siemens ) describes dynamic address management techniques, and WO2008015148 (Siemens ) describes balancing of load across secure and non-secure computers. US2003/0214417 (Peltz et al ) describes an intelligent communications command and control system for a land-based vehicle. This specification describes use of an additional communication scheme for locomotive command data for use if the quality of a first scheme is not satisfactory. A monitor senses parameters indicative of quality on the first scheme, and a processor selects a second scheme if quality is unsatisfactory on the first scheme.
Other documents which describe approaches to train maintenance or management information communication are:

CN20112000553 (CSR),
CN201046769 (Z. Chen),
CN101574975 (Beijing Liujie Tech.),
CN201287714 (Beijing Gaotie Comm. Tech.), and
JP2006327551 (TMPKK).

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

SUMMARY OF THE INVENTION

The invention provides a train diagnostics system as set out in claim 1.
By maintaining at least two channels the wireless interface may optimise data transmission without need to select and switch to alternative communication schemes. For example, if travelling through a tunnel, there is automatic use of the backfill channel and immediate re-use of the maintained live channel upon exit.
In one embodiment, the wireless interface is adapted.to execute a separate software processes for each of said live and backfill channels.
Preferably, the server controls the back-fill channel to abort a back-fill message if 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 a current state of each of a plurality of the train signals being monitored, and to compare new data received in a signal with a current known state for each of the signals, and wherein the on-board control unit is adapted to transmit new data if the current 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 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 event processing engine is adapted to maintain in memory not only a 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 parameter event value is received from the on-board control unit, update memory with new parameter event values and to discard oldest event values if they are older than the defined session time.
Preferably, the event processing engine is adapted to, when analysing 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 diagnostics 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 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.
Preferably, the server is adapted to monitor wheelset traction motors which are powered from a same source inverter by monitoring wheelset rotation speed differences to determine if excessive strain is likely to be put on a traction motor.

DETAILED DESCRIPTION OF THE INVENTION

Brief Description of the Drawings

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.

Description of the Embodiments

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 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 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 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-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 30. 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-Ethernet™ 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.
In many scenarios, it is desirable to monitor equipment 32 that does not provide a data interface for diagnostics data. Examples are air pressure 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 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 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. The EP engine 53 applies a series or set of user define(able) algorithms. These algorithms identify trends, scenarios and conditions in the diagnostic data as the data is received. These scenarios and conditions are used by the EP engine 53 to determine faults or the potential likelyhood of a fault occurrence.

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 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-stamped 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 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 under 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 wheelsets 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 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 (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 (Nackl) 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 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 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 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 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.
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 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 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 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 processed 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.
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 diagnostic data (New events) from the train vehicles 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 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 the 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 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:

The event processing engine 53 waits for a period of time (e.g., 1 hour) after the data is received before it is analyzed. This provides sufficient time for all of the backfill data to have been received before it is analyzed.
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.

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 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.
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 1 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.
It will also be appreciated that the invention achieves excellent real time performance in diagnostics data communication. This is especially because the transceiver uses in parallel at least two channels, namely the live and backfill channels, with transfer of individual messages or strings between the two according to real time conditions.
The invention is not limited to the embodiments described but may be varied in construction and detail.

Claims

A train diagnostics system (1) comprising:
an on-board control unit (2) linked by a local area network to interfaces (5) to train systems (34) and sensors (32),

a wireless interface for transmission of diagnostics data from the on-board control unit (2) and

a ground-based server (3) adapted to receive said diagnostics data and process it to generate diagnostic reports;

the wireless interface (5) is adapted to transmit the diagnostics data in a plurality of channels including:
a live data channel, and

a backfill data channel for data not successfully transmitted in the live channel, and

the wireless interface is adapted to automatically hand over from the live channel to the backfill channel a message for which a positive acknowledgement has not been received when transmitted on the live channel, and

the wireless interface is adapted to automatically assign data to the backfill channel if wireless communication is not available in real time,
characterised in that the on-board control unit (2) 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,

the server (3) includes an event processing engine for maintaining a live session for each of a plurality of trains, 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 a plurality of parameters being monitored, and to perform data processing to evaluate performance of the on-board train sensors and systems, and,

the server event processing engine 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 analyzed, to provide sufficient time for all of the backfill data to have been received before it is analyzed, and

run once periodically and analyze all of the backfill data received since it last ran.
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 live and backfill channels.
A train diagnostics system as claimed in any preceding claim, wherein the wireless interface is adapted to send a heartbeat message to the server at periodic intervals.
A train diagnostics system as claimed in any preceding claim, wherein the on-board control unit is adapted to maintain in memory a current state of each of a plurality of the train signals being monitored, and to compare new data received in a signal with a current known state for each of the signals, and wherein the on-board control unit is adapted to transmit new data if the current state has changed for one or more of the signals.
A train diagnostics system as claimed in any preceding claim, 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 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.
A train diagnostics system as claimed in any preceding claim, wherein the event processing engine is adapted to maintain in memory not only a 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 parameter event value is received from the on-board control unit, update memory with new parameter event values and to discard oldest event values if they are older than the defined session time.
A train diagnostics system as claimed in any preceding claim, wherein the event processing engine is adapted to, when analyzing the backfill data, include both data that was received live on the live 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; and wherein the event processing engine is adapted to perform analysis of event data over rolling windows of time.
A train diagnostics system as claimed in claim 8, wherein 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; and wherein the event processing engine is adapted to apply a time window during which the state of the channel may be changed.
A train diagnostics system as claimed in any preceding claim, wherein the server is adapted to maintain a live session for each train that is transmitting data; and wherein the server is adapted to maintain a sliding window of all channel data values over a configurable period of time, and to evaluate a value for a channel over this window of time.
A train diagnostics system as claimed in claim 10, wherein the value is a derived value.
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 diagnostics data with data from other sources.
A train diagnostics system as claimed in any preceding claim, 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 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.
A train diagnostics system as claimed in claim 13, wherein the server is adapted to monitor wheel set traction motors which are powered from a same source inverter by monitoring wheelset rotation speed differences to determine if excessive strain is likely to be put on a traction motor.