WO2004024531A1

WO2004024531A1 - Vehicle on-board diagnostic system

Info

Publication number: WO2004024531A1
Application number: PCT/GB2003/004115
Authority: WO
Inventors: Vincent Arthur Smedley; Laurence A. Steijger
Original assignee: Bombardier Transportation Gmbh
Priority date: 2002-09-13
Filing date: 2003-09-15
Publication date: 2004-03-25
Also published as: GB2409904A; GB0507533D0; GB2409904B; GB0221190D0; GB2392983A; AU2003269181A1

Abstract

A diagnostic apparatus and method for monitoring a system including a plurality of monitored components. The diagnostic apparatus includes sensors for generating measured data relating to the operation of the monitored components and sensors for generating environmental data relating to the current operating environment of the system. Data processing means receives the measured and environmental data and correlates at least a portion of the data to generate condition data relating to the condition of the system. Data transmission means transfers at least a portion of the condition data to an external data processing system.

Description

VEHICLE ON-BOARD DIAGNOSTIC SYSTEM

The invention relates generally to the field of monitoring the condition of a vehicle or fleet of vehicles using an integrated on-board system able to communicate with remote off-board systems, for vehicle condition monitoring and fault diagnosis and analysis. It is also applicable to any remote systems monitoring, fault diagnosis and analysis, for example of machine tools or buildings.

Over the years, trains have developed into complex systems with a large number of subsystems and components. Despite this increasing complexity, train operators have sought ever greater levels of reliability from their trains. At the same time, maintainers seek improved maintainability, better fault diagnosis and reduced maintenance resource costs.

On-board train control systems have been developed which collect data relating to the operation of the train necessary for driving the train. However, the type of data collected by these systems is typically limited to the data necessary for control of the train drive systems and to provide the train driver with basic operating information.

The current Euromain and TrainCom projects of the European Union are projects to develop common systems and protocols for real-time diagnostic and maintenance support systems for trains. Their objective is to standardise and improve train maintenance, maintenance procedures, and documentation. These projects envisage a system on-board a train to collect data relating to various aspects of the train and transmit the data to off-board systems for analysis at a maintenance centre. Alarms may be generated when a sensor signal passes a threshold.

The recent ROSIN project of the European Union describes communications standards and protocols that enable different systems from different manufacturers to be interconnected. The objective of such interconnection is the control through a single system of various on- board assemblies and sub-systems such as doors, lights, intercom, braking systems and traction systems.

The previous on-board systems have focused on collecting and transmitting data for off- board analysis or providing basic feedback systems required for the control of the vehicles or vehicle components. On-board analysis of data has been limited, restricting the usefulness of such prior art systems.

The present invention addresses these problems by providing an on-board diagnostic apparatus including sensors for monitoring the train, data processing means for analysing the sensor data, and data transmission means for sending the data to an off-board control centre.

The present invention provides a diagnostic apparatus for monitoring a system including a plurality of monitored components. The diagnostic apparatus includes a plurality of sensors for generating measured data relating to the operation of the monitored components, one or more sensors for generating environmental data relating to the current operating environment of the system, data processing means for receiving the measured data and environmental data and correlating at least a portion of the data to generate condition data relating to the condition of the system, and data transmission means for transferring at least a portion of the condition data to an external data processing system.

The diagnostic apparatus may include pre-processing means for determining if the data is reportable and communicating the data to main processing means if the data is reportable. Local storage means for storing data from the pre-processing means may also be included.

The diagnostic apparatus may also include a footprint relating to one or more of the monitored components or the system. The footprint may include data identifying the normal operation of the component or the system, data relating to acceptable variances in the normal operation data, and one or more thresholds relating to one or more levels of reportable conditions. The footprint may also include data relating to how much data is to be stored by the diagnostic apparatus for later transfer to the external data processing system, or data relating to additional sensors or systems to be polled as a result of detection of one or more reportable conditions, or data relating to pre-processing or processing of measured data to be performed as a result of detection of one or more reportable conditions.

The diagnostic apparatus may include virtual sensors for generating virtual measured data representing calculated physical values, the virtual measured data generated from inputs comprising measured data from one or more sensors or external systems.

The invention also includes a method for monitoring a system having a plurality of monitored components. The method includes collecting measured data relating to the operation of the monitored components, collecting environmental data relating to the current operating environment of the system, correlating at least a portion of the data to generate condition data relating to the condition of the system, and transmitting at least a portion of the condition data to an external data processing system.

Another aspect of the invention is a diagnostic apparatus for monitoring a system including a motor. The diagnostic apparatus includes one or more sensors for generating measured motor data relating to electrical current drawn by or voltage across the motor, the measured motor data including amplitude of the electrical current or voltage, and data processing means for receiving the measured motor data, analyzing the data over a time period to generate data relating to variations in the amplitude, frequency or phase of the data, comparing the generated data with amplitude, frequency or phase data characteristic of one or more predetermined conditions of the system, and generating an output indicating occurrence of one or more of the predetermined conditions as a result of the comparison with the footprint data.

A further aspect of the invention is a diagnostic apparatus for monitoring a system comprising a rotating shaft. The diagnostic apparatus includes one or more sensors for generating measured data relating to stress or torque on the shaft, the measured data including amplitude of the stress or torque, and data processing means for receiving the measured data, analyzing the data over a time period to generate data relating to variations in the amplitude, frequency or phase of the data, comparing the generated data with amplitude, frequency or phase data characteristic of one or more predetermined conditions of the system, and generating an output indicating occurrence of one or more of the predetermined conditions as a result of the comparison with the footprint data.

While the invention is phrased in terms of vehicles, especially of railway vehicles, it is equally applicable to any population of equipment that needs remote monitoring, e.g. machine tools at customers' sites, buildings, oil rigs, pumping stations and other fixed and monitorable installations.

The following is a description of embodiments of the invention, by way of example only and with reference to the following drawings, in which:

Figure 1 is a block diagramme of an embodiment of a diagnostic monitoring system. Figure 2 is a block diagramme showing major components of the diagnostic monitoring system of Fig. 1 embodied in a 4-vehicle train.

Figure 3 is a block diagramme of a virtual sensor.

Figure 4 is a plan view of a bogie showing the location of axle sensors.

Figure 5 is a side view of a bogie showing the location of axle sensors.

Figure 6 is a flow diagramme of showing an analysis of sensor data.

Figures 7 A to 7E are graphs showing output and analysis of vibration sensor data. Figure 8 is a cross-sectional diagramme of ball bearing showing the main potential defect sources

Figure 9 is a flow chart showing the frequency analysis of data from on-board sensors

Figures 10 A to 10D are cross-sectional diagrammes various types of defects in a ball bearing.

Figures 11 A to 1 ID are graphs of characteristic vibrations generated by the ball bearing defects of Figures 10A to 10D

Figure 12 is a block diagramme showing the detection, transmission, recording and transmission of a disturbance.

Figure 13 is a decision tree for the detection, transmission, recording and transmission of a disturbance.

Figure 14 shows a flow chart of the analysis of the dynamic attributes of a disturbance.

Figure 15: schematic diagramme of the correlation between the expected and actual cooling curves of an air conditioning system

Figure 16 is a timing diagramme for counting fleeting faults.

Figure 17 is a schematic chart of the relationship between engine output power and expected vibration or stress.

Figure 18 is a flow chart of the analysis of all inputs to identify reportable conditions, allowing for wear and tear.

Figure 19 is a decision tree showing how much data to store. Figure 20 is a decision tree showing which sensors to poll for data.

Figure 21 is a decision tree showing when to transmit data.

Figure 22 is a decision tree showing which data to transmit.

Figure 23 is a decision tree showing the selection of transmission means.

Figure 24 is a decision tree showing which data to store on-board.

Figure 25 is a decision tree showing where to store data on-board.

Figure 26 is a block diagramme of an on-board diagnostic system connected to multiple communication means.

Figure 27 is a flow diagramme showing the scheduled data exchange process for low priority data.

Figure 28A is a flow diagramme showing the scheduled data exchange process for low priority data initiated by the on-board system.

Figure 28B is a flow diagramme showing an alternative scheduled data exchange process.

Figure 29 is a flow diagramme showing the scheduled data exchange process for low priority data initiated by an off-board person.

Figure 30 is a flow diagramme showing the scheduled data exchange process for low priority data initiated by the off-board system. Figure 31 is a flow diagramme showing the unscheduled data exchange process for high priority data initiated by the off-board system.

The embodiments described below relate to a diagnostic system employed on-board a vehicle in a train. However, the diagnostic system could find application in many different environments, including for example the monitoring of machine tools at a manufacturing site, monitoring of all equipment within a building, or monitoring of oil rigs, pumping stations and other fixed and monitorable installations.

In an example embodiment, a diagnostic system is installed on a train to monitor the current condition of the train and identify any conditions or faults in the train that may require remedial action, in order to improve the operation, maintenance and reliability of the specific train being monitored and the vehicle class as a whole. The signals relating to these faults are correlated with environmental conditions such as location and ambient temperature. To monitor these conditions a system can be used that included diagnostic computers, digital input / output modules, sensors, links to proprietary condition monitoring systems incorporated in some components and assemblies, links to the vehicle's control system programmes, and a data bus to link them all.

Figure 1 is a block diagramme showing major components of a diagnostic system. Multiple data acquisition sensors 11 are connected to a sensor pre-processing means 12 which communicates with a local storage means 13. The pre-processing means 12 is connected via a Multifunction Vehicle Bus (MVB) 14 to the vehicle's main processing means 15 and its associated main storage means 16. The processing means 15, which in turn is part of the main Vehicle Control Unit (VCU), is connected to data transmission means 18. An additional communications means 17 is provided to provide for communication between different vehicles comprising the train.

Figure 2 shows an example arrangement of the diagnostic system of Figure 1 within a multi- vehicle train. In this embodiment the train is composed of 4 vehicles, including DMOS (Driver Motor Open Saloon) cars and MOS (Motor Open Saloon) cars. A diagnostic system is installed in each car. Diagnostic systems can also be fitted to trailer cars, freight cars, locomotives etc. Within each car, groups of sensors 11 monitor various train subsystems. The signals generated by the sensors 11 are transmitted to various analogue input/output modules (AI/O), digital input/output modules (DI/O) and serial interface modules 21 which convert the various types of signals generated by the sensors signals into digital sensor data suitable for use by the diagnostic system. The sensor data is sent to pre-processors (PP) 12 with their associated local data storage (LS) 13, and are then sent over MVB (Multi Vehicle Bus) 14 to processing means VCU 22 and its associated main storage means (MS) 16.

MVB 14 is preferably a distributed databus architecture designed to be suitable for a railways environment. The VCU 22 is connected to data transmission means 23 for interface to off- board data storage and data processing systems. In this embodiment, the transmission means 23 includes a GSM (Global System Mobile) module, which also has a GPS (Global Positioning System) subsystem associating geographic location data to data incoming to the VCU.

hi this embodiment, the VCU 22 communicates sensor data between cars via a gateway 24 and Wired Train Bus (WTB) 25. One of the VCUs, in this case the one in the trailing vehicle (in order to reduce the processing load on the VCU in the leading vehicle) takes control of the complete train system. Thus a single VCU 22 and its associated transmission means 23 provides an interface to off-board systems for diagnostic data from throughout the train. In this example embodiment the train is composed of 4 vehicles. There are DMOS (Driver Motor Open Saloon), and MOS (Motor Open Saloon) cars. A diagnostic system is installed in each of the cars. Diagnostic systems can also be fitted to trailer cars, freight cars, locomotives etc.

As soon as a fault occurs, an event is processed by the main processing means and stored in its associated main storage means. Since there is no direct connection between the diagnostic system and the train control system circuits in this embodiment, the train remains fully operational with its safety and reliability unaffected by the diagnostic system. It follows from this that it is not the purpose of the diagnostic system in this embodiment (though it could be in other embodiments) to initiate protection functions such as drive interlocks, speed reduction and HV (High Voltage) trips.

Sensors

The on-board diagnostic system comprises a number of sensors for monitoring the current physical status of various components of the train, interconnected with a processing means on board the vehicle. This processing means monitors the data output from the sensors, performs such correlations and data processing as are appropriate, stores them for transmission and then transmits the processed data to an off-board control centre via an onboard data transmission means.

The sensors used in the diagnostic system may include physical devices for measuring variables such as temperatare, pressure, movement, proximity, electrical current and voltage, and any other physical variable of interest. These "physical" sensors, such as accelerometers, temperature sensors, stress transducers, displacement transducers, ammeters, voltmeters, and limit switches, generate measured data indicative of the physical variables they sense.

Table 1 below shows an example of the subsystems monitored and the data collected by an on-board diagnostic system.

TABLE 1

Table 1 above provides examples of measurements to monitor the condition of major subsystems of a train, showing the types of sensors and transducers employed to monitor various aspects of the subsystems and the types of interface modules required for the diagnostic subsystem to receive the signals generated by the sensors (in the Interface column, Dl means Digital Input module, i.e. an "on-off switch, Al means Analogue Input module, AX means additional analogue Input/Output module, PT100 1 Al means an Analogue Input module accepting input from a platinum RTD temperature sensor. Table 1 also shows for each vehicle subsystem the vehicle functionality being monitored.

Data regarding the current environmental conditions is also collected, so that the data generated by the sensors monitoring the train subsystems can be analysed to identify the real causes and effects of the faults or of particular conditions. Table 2 below lists of environmental data gathered for correlation with the on-board sensor data gathered, in order to elucidate the causes and effects of different measured conditions.

TABLE 2

In addition to these physical sensors, the diagnostic system may also include "virtual" sensors which derive an estimated value of a physical variable by analysing measured data from one or more physical sensors and calculating an estimated measured data value for the desired physical variable. Virtual sensors may be implemented using software routines executing on a computer processor, hard-wired circuitry such as analogue and/or discrete logic integrated circuits, programmable circuitry such as application specific integrated circuits or programmable gate arrays, or a combination of any of these techniques.

Figure 3 is a block diagram showing a software implementation of a virtual sensor 30. Data inputs 31 from various systems (1, 2, 3, 4) such as software triggers, limit switches, sensors primarily relating to other components, signalling data, control data, location data, track layout is processed in a virtual sensor model 32 that generates an data output 33 that simulates what the output would be from a real sensor. For example, power transmitted to the wheels may be simulated from the power drawn from the overhead line (in the case of an electric vehicle), the gear setting (from the control system) and a model of power losses through the system (in the software).

This type of analysis of measured data from one or more physical sensors can be used to reduce the required number of physical sensors. For example, vibration sensors on two axle boxes may be used to monitor vibrations on the third and fourth axle boxes on the same train bogie by monitoring the comparative strength and time of measurement of the vibrations at each sensor.

Virtual sensors may also be used to calculate an expected state (e.g. vehicle location, door position) based on measured and calculated data (e.g. door location when closed or open) and elapsed time. Another example of a virtual sensor is the calculation of expected power applied to the wheels based on the driver's commands (e.g. speed setting, accelerator depression). Data from virtual sensors may be correlated with equivalent data from real sensors in order to identify variances between predicted and measured states. For example, the position data from the door position virtual sensor could be used to predict when the door should be fully open. This predicted time is correlated with the time of the door being measured by a real sensor as fully open to identify whether or not the door actuator is faulty. As another example, the predicted power transmitted - calculated as above by monitoring the driver's cab controls - could be correlated with actual power transmitted at various points (for example, outputs of the engine, gearbox and transmission shaft) to identify faults in the drive train and in the control systems for the drive train.

Data Analysis On-board data processing can be used to derive more advanced condition monitoring data than can simple sensing data; it can also be used to reduce the number of sensors required to monitor the train and to derive data that cannot be directly measured.

Figure 4 shows a plan view of a bogie 40 for a railway vehicle and Figure 5 shows a side view of the bogie, showing one arrangement of sensors to measure axle vibrations. The bogie has two axles 41 and 42. Each axle has an axle box 43-46 at each end. Vibration sensors

(accelerometers) 51 and 52 are shown mounted at axle boxes 44 and 46 to measure vibration.

Vibration sensors 53 and 54 are shown mounted on the bogie frame above the axle boxes 44 and 46. Sensors 53, 54 can provide data indicating the effectiveness of the primary suspension and damping systems, when their outputs are compared with the outputs from sensors 51, 52 on the axle boxes. Sensors may also be mounted at axle boxes 43 and 45 and on the bogie frame above these axle boxes.

One or two of the accelerometers in each set (the axle-box mounted set or the bogie mounted set) may be replaced by virtual sensors, with the signals from the real sensors being processed and compared, and the time for a given shock reaching the real sensors analysed, to identify what the output from the missing sensors would be. To use the minimum number of sensors, a preferred arrangement is to have the axle-box mounted accelerometer and the bogie-mounted accelerometer on one corner of the bogie, the axle-box mounted accelerometer only on a second corner, the bogie-mounted accelerometer only on the third corner and no accelerometer on the fourth: the different signals and time delays of shocks from each can be analysed to simulate the presence of the four missing accelerometers of the eight described in Figures 4 and 5. Figure 6 is a flowchart showing the processing of sensor data at both the pre-processing means 12 and the main processing means 15, to generate both alarm and non-alarm data. At the pre-processing means 12, three types of decision are arrived at: generate alarm; store data; and discard data. At the main processing means 15, the decisions are to generate an alarm or to store data for later retrieval by either scheduled transmission or interrogation from elsewhere. In this diagramme, using accelerometer input as an example, the signal 61 from the sensors is transmitted into the pre-processing means 12. There, it is processed by analysing the signal for key characteristics (62), in this case frequency and amplitude. The start and finish time of the signal is attached to the file (63), and the key characteristics are compared with thresholds from a footprint file (64). As a result of this comparison, the preprocessing means 12 decides whether to raise an alert, store the record or discard it (65) (in this case, by retaining it but allowing it to be overwritten when the store is full; this ensures maximum available data). Alert or stored data is transmitted by the MVB 14 to the main processing means 15. Inputs from other systems 66 are also transmitted by the MVB 14 to the main processing means 15. The signal is then processed to obtain the derived condition of various components and systems on the vehicle from the input signals (67), including when appropriate the alert from the subsystems. From this there are three outputs: an alarm (68) which is transmitted by an unscheduled transmission (70) by the transmission means 18 to an off-board system; data for regular transmissions and background data for regular interrogation (71). Both of these last outputs are stored in the storage means 16; the former are scheduled for regular transmissions (72) and sent during such transmissions. Analysis of the frequency spectrum of vibrations detected on an axle may be used to identify defects in vehicle and in the track. In one embodiment this is done by analysing the frequency and magnitude of each vibration to detect the characteristic frequency of a defect. Figures 7A and 7B are bar graphs showing data from vibration sensors resulting from different types of track and vehicle conditions. The vertical axis for each graph is the fast Fourier transform of acceleration value from the sensors and the horizontal axis is distance travelled measured in a multiple of wheel rotations (a count of one relates to fifty wheel rotations) One set of data is shown in each of Figures 7 A and 7B. The resulting bar graphs show characteristic results for certain conditions relating to the vehicle and the track. The conditions which produced the graphed data are: corrugated track (74), crush (full load in the vehicle) (75), deflated suspension air bags (76), jointed track (77), rail roar (78) and tare (no load in the vehicle) (79).

By analysing the frequency of a signal, the cause can often be determined. For example, Figure 7C shows how the frequency of a fault signal will vary with vehicle speed for a fault on an intermediate drive shaft (between the engine and the gear box) of a vehicle with gears. As the vehicle speed increases, the drive shaft rotational speed will increase and the frequency signal will increase correspondingly. When the vehicle changes gear, the rotational speed of the shaft (and hence defect signal frequency) will decrease suddenly before increasing again, but at a slower rate corresponding to the gear ratio.

Figure 7D illustrates how the frequency of a signal relating to a final drive shaft fault will increase with vehicle speed. Because the shaft is not affected by gears, the shaft rotational speed will continue to increase linearly with vehicle speed.

Figure 7E illustrates how the frequency of a signal relating to joints in jointed track will vary over distance travelled by the vehicle. Since the signal from such a joint resembles white noise, the signal over each joint is unchanging. However the occurrences of this signal will be more frequent as the train speed increases because the train will cross between such joints more rapidly.

Analysis of the frequency spectrum of vibrations detected on a drive shaft bearing may be used to identify defects outside the bearing, for example defects in gear cogs, in wheel bearings and in track. In one embodiment this is done by analysing the frequency and magnitude of each vibration. Each defect has its own characteristic frequency, such frequency being dependent on the object being monitored. For example, the characteristic frequency of a missing gear tooth is related to the rotational frequency of the gear. A chip in a bearing roller will be related to the frequency of rotation of the roller. A crack in a bearing race will be related to the frequency at which bearing rollers or balls run over that race; this frequency will be different for each race due to their differing diameters. .

Figure 8 shows a bearing 80 with a balLrace having inner and outer walls 82 and 83 of different diameters. The balls 81 are also of slightly different diameter. A sensor 84 on one part of the bearing measures vibrations of the bearing. Defects in any of the parts 81, 82 or 83 of the bearing would cause the sensor 84 to generate signals at different frequencies, depending on the speed of rotation of the defective part. Thus by analysing the frequency of the sensor data from sensor 84, a single sensor will be able to monitor many such parts for defects and identify the exact part in which a defect occurs.

Figure 9 is a flowchart showing the process for detecting and identifying drive shaft ball bearing failures by analysing small variations in the current drawn by an electric motor. The current frequency from the electrical motor is sampled (91) and analysed (92) to measure the exact current drawn at distinct values of frequency. Those values are then compared to several "footprints" (93). These footprints identify frequencies of signals with the component that may cause signals at such frequencies. Most (but not all) such frequencies would be related to the rotational speed of the shaft(s) in the motor. Other signals may be related to the electrical supply frequency, to computer clock frequency, to systems polling frequency, or may have entirely different correlations. These footprints include thresholds for what is considered normal and what is considered reportable. The signal is compared with these thresholds in a footprint recognition capability (94). A diagnostic decision logic (95) can then recognise footprint-identifiable faults. It also identifies threshold-breaking conditions that do not correspond with any known footprint.

Figures 10A-10D and 11A-1 ID show the different frequency "footprints" corresponding to several different defect types that may be expected to occur in a bearing. Figure 10A shows a ball bearing with a defect 100 in the outer race, and Figure 11A shows a graph of the vibrations generated during rotation of the bearing as a result of the defect. The graph of Figure 11 A shows vibration amplitude on the vertical axis and frequency on the horizontal axis. The characteristic vibrations generated by the defect 100 appear at certain frequencies corresponding to the diameter of the surface on which the defect 100 appears and the rotational speed of the ball bearing. These characteristic vibrations can be analysed to determine what kind of defect exists in the ball bearing.

Figure 10B shows a ball bearing with a defect 100 in the outer race combined with eccentricity 101, and Figure 1 IB shows a graph of the vibrations generated during rotation of the bearing as a result of the defects. The graph of Figure 1 IB shows the same characteristic vibrations generated by the defect 100 as in Figure 11A, but also vibrations at additional frequencies corresponding to the defect 101. Figure 10C shows a ball bearing with a defect 100 in the outer race combined with a ball diameter defect 102, and Figure 1 IC shows a graph of the vibrations generated during rotation of the bearing. Figure 1 IC shows the same characteristic vibrations generated by the defect 100 as in Figure 11 A, but also vibrations at additional frequencies corresponding to the defect 102. Figure 10D shows a ball bearing with a defect 103 in the inner race, and Figure 1 ID shows a graph of the vibrations generated during rotation of the bearing. The graph of Figure 1 ID shows the characteristic vibrations generated by the defect 103.

A track-related defect will generate a short burst of vibrations repeated once as the second wheelset on a bogie passes over the defect. All of these defects can be more accurately identified, located and quantified by correlating the results of such frequency analysis with indications from other sensors. From Figures 8-11, it can be seen that track-related features and defects can also be detected by the frequency analysis of on-board accelerometers. As with on-board data, the frequencies generated by some off-board data (e.g. track corrugation) will be related to the speed of the train; others will have characteristic signals occurring at a regularity that varies, with the speed of the train (e.g. track joint locations), and others will have more complex relationships with speed.

Optionally, some initial pre-processing is performed at the sensor or in a sensor subsystem, for example to monitor whether or not the data is reportable. A disturbance message is generated at the process control level (i.e. the sensor subsystem, incorporating the local preprocessing means and its associated storage means) when an abnormal condition is detected that among other things initiates the creation of a diagnostic data set (DDS). In addition to the disturbance data, the data set includes what is referred to as the environment data that describe the status of the process at the instant of the disturbance. The DDS is transmitted to the diagnostic computer, which is this embodiment of the main processing means, as shown . in Figure 12. The transfer of the DDS to the diagnostic computer is preferably event- controlled, although it could also be initiated cyclically.

In the system depicted in Figure 12, a signal 121 detected from a sensor (either real or virtual) is analysed on-board in a sensor-related pre-processing system 122 for any variance from a normal or expected condition from a "footprint" store 123. The signal is correlated with related "dynamic attributes" 124 from other sensors, and with the time and location at which it occurs, from a GPS location signal 125, in the diagnostic transmitter 126. A dynamic attribute is additional data useful for understanding the cause of the event, such as time of malfunction and operation being undertaken at the time of malfunction. If the programmed or logically derived conditions are met, an alert is transmitted to the main vehicle diagnostic computer 131, which stores it in the storage means 127 and may perform further analysis 129, correlating it with data from elsewhere 128. If the system is transmitting the data to the off-board control centre, it is then passed to the GSM link 130. This is performed according to the decision tree in Figure 13.

Figure 13 describes the decision tree for transmitting alerts that correspond to events which have been identified by the pre-processing means as a high priority notifiable condition. Initially a signal 1 is detected for which some pre-processing 2 is performed which consists in adding some dynamic attributes 4 corresponding to additional data useful for understanding the cause of the event and a geographic position 5. This is analysed against the footprint 3 which carries threshold conditions giving the level(s) an event at a given frequency should be considered as a recordable, notifiable or alert condition. The diagnostic transmitter determines whether or not an alarm or non-alarm notifiable condition exists. If a notifiable condition exists, an alert 6 is sent to the main on-board diagnostic computer, which may perform further analysis 7 such as more detailed analysis of trends, frequencies, regularity of occurrence, peak amplitudes, duration of alert condition, prior alerts, prior condition etc. The main processing means may also poll further systems for further data 8 from elsewhere. Having performed this second analysis, the system identifies whether or not an alarm condition exists. If not, the data is recorded for later download or interrogation 9; if so, it transmits the alarm data 10. If on the first analysis a non-alarm notifiable condition is identified, the system polls related systems 11 for relevant data prior to recording 9. If the condition is non-reportable, the data is discarded 12. Having recorded data 9 for later download or interrogation, this data is transmitted 10 when an appropriate download operation is instigated, whether automatically, logically or externally. The DDS (Dynamic Data Storage) record is generated and stored by the diagnostic computer (DC) and transmitted by the transmission means during download.

Figure 14 looks in more detail at the analysis of the dynamic attributes, represented as 4 in Figure 13. To analyse the dynamic attributes of a disturbance, the diagnostic transmitter adds the dynamic attributes to a DDS before it is sent to the diagnostic computer. These dynamic attributes may include:

Disturbance identifier (disturbance transmitter number, disturbance number identifying the nature and/or magnitude of the disturbance);

Active flag, which indicates whether the leading edge (start) or the trailing edge (finish) of a disturbance is concerned. A disturbance record in the diagnostic database of the DC is still active for as long as the record does not include a stop time. Active disturbances, depending on the nature of the disturbance, may impair the proper functioning of the vehicle. A fleeting disturbance develops from an active disturbance when a function previously diagnosed as being defective works properly again;

Date and time of the event (preferably in Unix format);and Environment data, which describes the status of the process at the incidence of the disturbance. These might include the vehicle load, line voltage and the physical location of the vehicle.

Figure 14 shows the gathering of dynamic attributes for a specific data type. The data 1 is correlated with the footprint 2 to identify the type of the data for which the dynamic attributes must be collected is retrieved from a configuration database. This will tell which specific attributes must be collected 3. Once those attributes are collected 4 from other systems or sensors 5 (which may be real or virtual), they are stored with the data 6 in a normalised form for later use.

Examples of such reportable data are data that exceed or fall below a threshold value, which threshold value maybe static or dynamic. An example of a calculated dynamic threshold is a rolling average or other such calculated value. For example, wheel slippage can be monitored by measuring the rotational speed of the wheels and comparing this to the expected wheel rotational speed. The expected rotational speed may be calculated based on accelerating or braking force applied, and on previous speed.

A dynamic threshold may also be based on measured data. For example, the performance, of an air conditioning system or engine cooling system, both of which must be compared with the measured external temperatare. Thus the inputs include: current outside temperatare, current inside temperature, time for which the air conditioning has been on, number of doors that have been opened including time and duration of opening. These are correlated with the expected cooling curve of the air conditioning system according to the flow chart in Figure 15. hi the example embodiment the thresholds are: 10% under-cooling rate and/or 5 degrees under-cooling. Thresholds may also be derived from a logical operation within the software or hardware.

Figure 15. show a typical flow chart for monitoring performance of a component. First operative conditions and data from the monitored component 1 are collected, as well as the overall system status including external data 2. These are compared 4 with the footprint 3 to identify whether or not the condition is notifiable. If there is an alert state, the alert data are sent 5 to the main on-board diagnostic computer. If the condition is notifiable but not as serious as to require an alert, it is recorded 6. Otherwise it is discarded 7. An example of the analysis 4 is to identify whether or not the internal temperatare of an air conditioning system is correct, by correlating the system data 1 (cooling power being used, start time of cooling) and external data 2 (external temperatare, the initial starting temperatare, the frequency and duration of door openings) with the footprint 3 (expected cooling profile given these criteria, the allowable variance, for example ±5% for non-alert notification, ±10% for alert notification).

Error Codes and Subsystems

Every disturbance is defined by a four-digit hexadecimal error code in the range 000 lh to FFFFh (where 'h' denotes 'hexadecimal format'). This range is subdivided into groups referred to as "subsystems" to which signals related either by function or location are assigned. Thus there is a clear association between the error code and the subsystem to which it belongs, namely the error code indicates the location of the fault diagnosed.

The subsystems are also grouped and have a descriptive text. All the standard subsystems have an identification number and are used for selecting subsystems.

Fault Class

Preferably four defined classes of faults are used for maintenance diagnostics. The significance of the Fault Classes A, B and C correspond to the "priorities" defined in UIC557, a standard issued by the Union Internationale des Chemins de Fer.

Fault Class A: A currently active fault that appreciably impairs the function of the vehicle, hi most cases, faults in this class require immediate action and if possible are signalled to the driver. Fault Class B: A currently active fault that does not appreciably impair the operation of the vehicle, but does require correction before the next scheduled service.

Fault Class C: As Fault Class B, but it is permissible to wait until the next scheduled service before correction.

Fault Class D/0: Not a real disturbance. The DDS is simply recorded to log certain operational procedures and events (DDS protocol).

The fault classes are used as information that contributes to the determination of alarm level or urgency, and corrective action to be taken; they also support later analysis of vehicles, fleets etc. from the databases in the off-board systems. There are many fault codes per fault class.

Other Fault Code Definitions Active And Fleeting Faults And Corrective Action: An active fault is defined

(according to UIC557) as a fault which appreciably impairs the proper functioning of the vehicle. A fleeting fault evolves from an active fault when the function previously diagnosed as being defective works again correctly.

Synchronisation: After switching on, the control system processors and the diagnostic computer are automatically synchronised. Any fault that was active at the time the control system was switched off and has disappeared in the meantime is tagged with the current time as stop time and designated as a fleeting fault.

Faults With Corrective Action: Corrective action has to be taken (by the driver or remotely by personnel in the maintenance control centre) in the case of serious faults. The corresponding fault must remain active at least until the driver or other suitable person has taken the corrective action. A subsystem may be isolated as a result of corrective action.

Faults Without Corrective Action: Faults in this category remain active until they are located and cleared. Faults With Corrective Action And Isolation: Where the correction of a fault means that the corresponding subsystem is isolated, the isolated status itself is signalled as an active fault to the diagnostic system. The fault that causes the isolation of the subsystem is also maintained as an active fault, but any faults in the subsystem disappear once it has been isolated.

Faults With Corrective Action That Are Not Isolated (e.g. disturbance events that are counted): In a first phase, faults caused by temporary events (e.g. an overcurrent) are counted and only after the event has occurred a given number of times is the corresponding subsystem isolated. The counting and evaluation of such events is a process function and not performed by the diagnostic system. The disturbance counters for counting the events can by either of the volatile kind (i.e. they start at zero every time the control system is switched on) or non-volatile cumulative kind.

A timing diagram is shown in Figure 16 illustrating the occurrence of active faults, fleeting faults and acknowledgements. In this diagramme (Figure 16), an overcurrent event 1 is detected as an active fault 2 that causes a corrective HN (High Noltage) trip by the protection mechanism 3. The event counter 4 is activated. The overcurrent event recurs 1, the fault is detected again 2, the corrective action 3 is taken a second time, and the counter 4 updates itself again. This time the subsystem is isolated 5 (which may be initiated by the system, the driver or another person on-board or off-board), which also is recorded.

Some time later, the same fault occurs again and the corrective action has to be repeated to clear it. This time, however, the maximum permissible number of occurrences for this fault has been reached and the subsystem is isolated.

Optionally, reporting may be performed by comparing vibration magnitudes with frequency- related thresholds. Thus the threshold for one type of defect with its characteristic frequency may differ from the threshold for another type of defect with another characteristic frequency, without necessarily using different sensors. As an example, the reporting threshold amplitude for a bearing race would be lower than the reporting threshold from a crank shaft owing to the greater magnitude of vibrations generated by a faulty piston. Moreover, owing to the natural vibrations from the firing of the pistons, such vibrations must not exceed the threshold under normal operating conditions. Since the sources of these vibrations generate vibrations at different frequencies, the threshold amplitude of vibrations at the characteristic frequencies related to the bearing race would be much lower than the equivalent threshold at the characteristic frequencies related to the crank shaft.

Correlation of Data The processing means receives raw or pre-processed measured or derived data from the real or virtual sensors or sensor systems of the on-board diagnostic system. It may correlate this data with data from other sources to derive additional data relating to the condition or performance of the train. Such data may be measured data, calculated or logically derived data or signal data.

One example of correlation between different sources of measured data is the correlation of measurements of vibrations or stresses within a drive shaft or drive shaft bearing with the output power of the engine. In this case there is a relationship between engine output power and the stresses or vibrations. This relationship may be determined from additional measured data inputs or may be calculated or derived logically using data programmed into the onboard diagnostic system. Engine output power can be measured by stress or torque analysis of the output shaft; alternatively, it can be derived (in an example of a virtual sensor) from the fuel or electrical power consumption and engine settings. As more power is transmitted by the engine, so the allowable stress on the shaft will increase. The relationship between output power and acceptable stress is pre-recorded in the footprint for the system, or could be developed by an intelligent system from readings taken during operation. If the measured stresses exceed allowable stresses, then depending on the level and duration of the excess stress, a signal or an alert is generated by the pre-processing means. If a virtual sensor is used, the main processing means will normally be the source of the alarm. Figure 17 show a example of derivation of engine stress 5 from engine power output 1, engine rotation speed 2 and engine vibration level 3, through a model 4 which estimates an engine stress level 5. There would be a margin for natural variation, so that circumstances such as normal and acceptable wear and tear, or acceleration up a hill, are not reported as a fault. Any deviation beyond the margin for variation is reported as a fault.

Figure 18 shows how a model of component wear (in this case, brake pads) is used to detect abnormal component wear using virtual sensors. Actual wear 5 is calculated from inputs the current weight on the bogie 1, the vehicle speed 2 from the odometer, brake actuation signal 3 which includes the notch setting to identify how rapidly the train will be braking, and track gradient 4 from a gyroscope. This data is fed into a wear model 5 to derive calculated brake pad wear 6. This is compared to an expected wear from a model / footprint 7 to determine if there is excessive wear 8. This illustrates how virtual sensors can replace real sensors; in this case one type of real sensor that could generate the pad wear 6 would be a means for measuring the movement in the brake calliper levers during braking operations. Optionally, the reported severity of the fault may be determined by the extent by which the vibrations or stresses exceed the allowable vibrations or stresses; such severity levels would be reported as different priorities of notification.

Another example is the correlation of the acceleration of a vehicle with the input power (e.g. the power drawn through the pantograph or pick-up shoe, in the case of electric vehicles). In this case the relationship between the input power and acceleration is input, calculated or derived logically.

Examples of correlation of either real or virtual sensor data with derived data include correlation of bogie vibrations or of wheel slippage with geographical location of the vehicle on the track. In this case the measured vibrations or slippage are correlated against data derived from elsewhere that identifies the location at which the slippage or vibrations occurred. Optionally, the reported severity of the fault may be determined by one or more of the magnitude, duration and variability of such slippage or vibrations; such severity levels would be reported as different priorities of notification.

An example of correlation of control signals with measured data is the measured delay between sending the signal to open a door and the door being detected fully open. In this case the measurement of door position, or the trigger signal stating that the door is open or shut, is recorded against data identifying the time at which the actuation signal was generated. Optionally, the reported severity of the fault may be determined by one or more of the delay in operation and the speed of movement of the door; such severity levels would be reported as different priorities of notification.

Data Management Functions

The on-board data processing means may also include decision-making capability. This capability may decide, for example, how much data to store, when to transmit data to the off- board data processing system, which sensors and/or sensor subsystems to poll for data, which data to transmit, the type of transmission means to use for sending a particular set of data, which data to store on-board, where to store each data set, and the priority or severity of the notification.

The on-board data processing means may determine how much data to store, taking account of the limited storage capacity of the on-board diagnostic system, by deciding for example, the sampling (or polling) rate for sensor data, the number of seconds before a reportable event to record from each sensor or derived data, and the sensors, sensor sub-systems or data sets from which to record them. The data from the individual sensor, where it is not further processed, is stored in the local storage means, if any, associated with the sensor. Any data that is further processed is stored in the vehicle's main storage means. Data buffers may also be used to temporarily store data before storage in the local or main storage means.

Figure 19 shows the decision tree for identifying sensor polling rates, local (to the sensor subsystems) processing and storage volumes in each on-board store. The parameters for these, and also the protocols, schedules and means for transmitting data on a scheduled basis or on overflow of those stores are programmed 1 when the diagnostic system is installed. These settings may be updated at any time 2, either remotely or locally (e.g. by maintenance staff or the driver). The system reads the current state of these parameters 3, which determine the data sampled 4 and processed locally 5. The system monitors the data stores 6 according to the same set of parameters 3. When scheduled transmissions are due, these are performed 7 according to those parameters 3. Additionally, when one or more stores are full (again as determined by the same set of parameters 3), the store is downloaded 7 according to the schedules and means as determined again by those parameters 3.

The on-board data processing means may also determine which sensors and/or sensor subsystems to poll for data, for example polling some of them for raw and/or pre-processed data that normally would not be reported to the processing means, because a related sensor or sensor sub-system has reported an event. This may be achieved for example by setting up a buffer on these sensors: if there is a reportable event the data from the buffer is reported; if not, it is discarded. The decision as to which data to draw from which systems is determined according to a pre-set (and amendable) file of relevant systems and subsystems. In this embodiment, the sub-systems to be polled are related to the fault recorded; in other systems, the sub-systems to be polled may be related to the system in which the fault is found. Such data stores may be related to a single sensor, to a subsystem, to a vehicle or to the entire train.

In a preferred embodiment, as shown in Figure 20, the subsystem related to each sensor or system identifies notifiable data 1, 2, 3, 4. On identifying notifiable data, the subsystem notifies the main on-board diagnostic computer 5. This looks up the footprint 6 of each notifiable event to identify which additional sensor or system date needs to be correlated with the notifiable event data. It then polls all related sensors and systems 7 for data related to the appropriate duration before the event. This data is then processed 8 according to the footprint, and the urgency of notification is determined 9 from the resultant processed data. The computer then notifies 10 the transmission control module that transmits 11 alarm data and scheduled transmission data as described previously. Non-urgent data is stored 12. The buffers are of limited size and therefore must be monitored 13 (in this case, by the transmission control module) to identify when they pass a threshold percentage full. The data is then transmitted 14 at the next opportunity, which may be defined as the next opportunity to transmit data based on given criteria such as specified transmission means and priority ranking (for example, alarm data taking higher priority in the transmission). This percentage full may be set at less than 100% in order to have spare capacity for further storage should an opportunity to transmit data not occur immediately.

The on-board data processing means may also determine when to transmit data, for example periodically; when reportable events occur; when other thresholds are breached; when buffers are full. Figure 21 shows an example of a process for scheduling data for transmission. The system notifies the transmission control module of all data requiring transmission, together with data labels that identify the data as being alarm type 1, notifiable for next scheduled transmission 2 or notifiable but not urgent 3. From this decision the transmission control module selects the appropriate means for such a transmission 5, those being unscheduled and immediate transmission 6, scheduled transmission 7 or storage for later download 8.

The on-board data processing means may also determine which data to transmit, for example all data; sets of data on a cycle; only the data from full buffers; only the alarms or reportable data; or data relevant to alarms or reports. Figure 22 shows an example of a process for scheduling data to transmit and transmitting it. The transmission control module polls all subsystems for data that needs to be transmitted 1. For each type of data, condition 2, event 3 or statas 4, the system checks if there is data available that requires scheduled transmission. Condition data relates to the current condition of the component or system, e.g. thickness of brake pad. Event data is data related to the occurrence of an event detected by a sensor, e.g. a shock or high amplitude vibration. Statas data relates to the status of the systems, e.g. door closed, brakes off, engine at idle. If it is, then the data is made available to a transmission queue 5, 6, 7 which schedules the exchange of it 8 with an off-board system as it becomes available. The system also selects the appropriate means for such a transmission 8, and transmits all the data 9.

The on-board data processing means may also determine the means for transmission of data to an off-board system, for example radio or cellphone transmission for urgent, alarm and or reportable data; local transmission technologies such as short-range radio for greater amounts of data within range of a local transmission station; partial or full download when stationary and within range of a local transmission station (by wireless Local Area Network or LAN); full download when in a maintenance location or when visited by maintainer. Figure 23 shows an example of different transmission means can be used to transmit data. The main diagnostic computer tells the transmission control module that data is available to transmit 1. The module 2 verifies the parameters for selecting means for transmission 3, which are in this case a hierarchy of transmission means for each transmission urgency level. For example, alarm data would be sent by radio link 4, 7; if unavailable the second choice is broad band 5, 8, and the third choice wireless LAN 6, 9. Scheduled transmission would be by wireless LAN as first choice 6, 9, broad band 5, 8 as second choice if no wireless LAN transmission is possible within a given time period, and radio means 4, 7 if broad band is unavailable. Non-urgent download is by wireless LAN at terminus station or depot only; if buffers are filled before reaching such a location, the selection would follow the criteria for scheduled transmission. Any other data with lower priority would be stored on-board until downloaded by a means selected and initiated externally or by on-board human intervention.

The on-board data processing means may also determine which data to store on-board, for example reportable conditions; all data related to reportable conditions; or all data (raw, pre- processed or processed). Figure 24 shows an example of the different types of data that may be stored. The setting up of which data to collect and when to collect it may be made at development or installation time and may be updated either locally or remotely. Condition data 2 is collected and stored on board on demand 6. Event data 4 is stored on-board as it is created 7. Statas data 5 is stored on board 8, for downloading normally on a cyclic period base. The subsystem storing the data notifies the main on-board diagnostic computer 9 of all data that is stored.

The on-board data processing means may also determine where to store each data set, for example in sensor-related 8 or central 9 data storage means awaiting transmission; in removable media 7 or in long-term on-vehicle storage 10 (e.g. for making vehicle and/or event history available to maintainers. Figure 25 shows an example of which decisions can be made. According to the type of storage media available on the application, the system will be pre-configured to prioritise the use of different storage media and locations for each type of data. In the present embodiment, if there is no wireless transmission means available on the vehicle, a removable media storage 3 will be used to store the data 7. If some of the sensors cannot be connected to a central diagnostic system, or if the pre-programmed selection criteria dictate it, the data 4 will be stored in local storage means associated with the sensors or groups of sensors 8. In the case of a main processing means with remote connection capacity, alert and processed data 5 will be stored in their main storage means 9. Any condition data that does not need transmission 6 may be stored in an additional on-board long-term storage 10. Any data that does not need to be stored at all will be discarded 11. The decision-making algorithms for these may be pre-programmed at installation, and the parameters by which these decisions making functions operate may be set during programming or at a later time. They may be re-set either locally (on-board or during maintenance) or remotely. In other embodiments the algorithms and/or parameters may be derived by logical or artificial intelligence functions.

The decision-making capability of the on-board data processing means may also determine the priority or severity of the notification, by means of multiple thresholds. One embodiment of such a prioritisation routine is to categorise the notification by anticipated time of required action, such as, in descending order of priority: Stop the train now

Stop the train at the next station or location to which an engineer can be sent Stop the train after this journey Maintain / repair overnight Maintain / repair within a week Maintain / repair at next planned maintenance . Maintain / repair at next overhaul For information purposes only

In a prefered scheme, the first four categories would trigger real-time transmission of the relevant data, the following two categories would trigger download at the end of a journey or of a day, and the final two categories would trigger downloading at the next maintenance if the data had not already been downloaded by that time. Again, the parameters for prioritising may be updated either locally or remotely.

The on-board diagnostic system may comprise one or more communication systems designed for communication using different communication technologies, such as radio, satellite, cellphone, infra-red, wireless LAN (Local Area Network, such as Bluetooth or 802.1 lb protocol), hard-wired (such as copper wire or fibre-optic connections) and any other transmission technology. Different such technologies may be used in different circumstances to achieve optimum communication between the on-board diagnostic system and off-board data processing systems. For example, the communication system to be used for a particular data transmission may be selected depending on vehicle speed and whether or not it is in range of an off-board receiving station for a good quality transmission. The communication system may also be selected based on the type or quantity of data to be transmitted, for example urgent data to be transmitted by long-distance technologies such as cellphone or radio, and less urgent data to be transmitted by short-distance (such as Bluetooth or 802.1 lb) and/or hard-wired technologies. The transmission may also be via download to a removable medium, such as CD-ROM, DVD-ROM, mini-disc, or removable hard disc, or via hardwired connection to a portable computer or other receiving equipment.

If more than one system is used for transmitting data, the on-board system may also include a means for determining which system(s) is/are within range of the on-board transmitter (s). One such determination means is to send out signals from the on-board system via one or more particular communication systems. This may be periodic, or may be performed when there is data available to transmit by such a communication system. The off-board system is programmed to identify itself in response. If the on-board system receives the correct response signal and the response signal strength is sufficiently great, then the on-board system considers that the particular communication system used is available. In the alternative or in addition to the above system, the off-board system may transmit identification signals either periodically or continually via different communication systems. The on-board system will then be able to establish which communication systems are available, the signal strength of each and the constancy of the availability and signal strength of each.

Figure 26 shows a block diagram of an on-board diagnostic system in which the main onboard diagnostic computer 1 is connected to multiple communication means that communicate with one or more off-board data processing systems using multiple complementary communication systems. In this embodiment the main diagnostic computer 1 communicates with the main on-board storage 2 and, through sensor-related subsystems 3 (i.e. the pre-processing means), with sensor-related storage 4 (i.e. the local storage means). It also communicates with on-board communication systems which include a wireless Local Area Network (LAN) transmitter / receiver 5, a radio transmitter/receiver 6, a broadband transmitter/receiver 7, removable media 8 and a port for hard-wired hook-up 9. The "hardwired hookup" may include wireless systems such as an infra-red data link. The off-board system includes communication systems corresponding to the on-board systems.

The radio transmitter-receiver 6 is primarily used as a long-range communication system for transmitting data required to be transmitted in real-time or near-real-time, such as data related to alarms. This transmission is typically initiated by the on-board systems, and the selection of transmission system is typically controlled by control centre staff. When the train is within range of a wireless LAN base station 5 for transmitting and receiving data from a fixed point on or near the infrastructure, data (primarily bulk and low-priority data) is transmitted using a broader-band, shorter-range device and protocol, for example an 802.1 lb wireless LAN (Local Area Network) microchip. This minimises the data traffic on the more expensive and narrower-band long-distance communication systems, while enabling full downloads to occur once for each journey or return journey. The wireless LAN station may be located only at a terminus station of a railway line, or may be located at intermediate stations to enable the transfer of lower-priority data at intermediate points on the vehicle's route. This arrangement increases the proportion of data transmitted using high speed, low cost techniques, while maintaining more up-to-date data in the off-board systems and reducing end-of-journey data transfer volumes. Removable media 8 and hard-wired download 9 are suitable for supporting depot work, but may also be suitable for use when the vehicle is at a terminus.

If at any time the frain starts moving or goes out of range during wireless LAN download (depending on whether vehicle movement or signal sfrength is set as a parameter of the transmission system selection algorithm), that download is interrupted and resumed when next within range of an appropriate wireless LAN receiver. Optionally, the wireless LAN system also carries those message exchanges that would normally take place over the long- range data communication system that occur while the vehicle is in range of the short-range base station. Optionally, the long-range system is used at all times for higher-priority messages, in order to simplify communications channels and the management of the data both on-board and/or off-board.

Transmission at the end of the day may be performed when vehicle systems are switched off or when the train is stationary for more than a given period of time. That time may be either during a predetermined part of the day or when within range of an off-board transmission device that identifies itself as being a device for receiving such "end-of-day" transmissions.

Data may also be downloaded using a hard-wired hookup or transferred via a removable medium. Condition Diagnosis

The on-board data processing means provides a facility for counting events subject to wear (Engine starts, engine running time, door closing operations etc.) and storing the totals in a non- volatile memory.

In order to permit later trend analysis (in this embodiment, to be performed in the off-board system), data may be stored for the development of certain parameters over a suitable time period. For this purpose, the system takes and records statas readings automatically at cyclic intervals. The file of cyclic readings will then be transferred to a central database, where this information can be interrogated. In this case, the counter readings can be presented, for example, as curves or bar charts in relation to time. Trends enable preventative maintenance to be efficiently planned (e.g. the door is closing very slowly, and therefore the runner gear should be checked).

Commissioning/Remote Testing

Related to this is the commissioning of vehicles, systems, software etc. by running tests remotely from the vehicle, or by running vehicle tests that are monitored remotely. In the first example, a vehicle's systems maybe switched on remotely and a specific programme ran, with its effects on vehicle components and systems being monitored. In the second example, a vehicle may be operated with new or adapted hardware or software, and related systems are monitored closely to verify that the hardware or software is operating correctly. This may be performed on a special commissioning run of the vehicle, or while the vehicle is in service. The invention incorporates on-board means for enabling a subset of such control and monitoring from off-board locations.

One example of remote testing of systems is of an air conditioning system. Staff in the control centre or elsewhere operate the system, and also monitor power drawn, external temperature and internal temperature (including rate of change of internal temperature).' They may also monitor fluid pressures, temperatures and vibrations in the system. Moreover, they may monitor other electrical systems to verify that they are not picking up critical interference signals.

An example of remote testing of software routines or bug fixes is for staff at the control centre or elsewhere to run the programme (or the section of the programme) while monitoring the functions that it performs. For example, if the programme confrols the power output of a transformer, the power output is monitored. Other programmes or routines may be run simultaneously, to verify whether or not there is interference or other conflict between the routines or programmes. Likewise, other related hardware may also be monitored to verify whether or not there are desirable or undesirable effects on them from the software being tested.

Again related to this is the capability to perform some vehicle operations remotely (by control centre staff or by users through the system) or on a pre-set schedule. Examples of such remote operations include opening doors before a train leaves a terminus station, starting locomotive engines before the locomotive is used, to warm it up, or turning on vehicle heaters ten minutes before first vehicle operations in winter, to avoid the need to have a driver present during those ten minutes.

Data Types

The data received from the vehicle is complex and can include several sub data types. In the embodiment described herein, the sub types are:

(1) Event data, which is a recording of data triggered by random fault or schedule timing;

(2) Environment data which is a snapshot of the vehicle state at the time of an event and contains information related to it (physical or virtual sensor output, sub-system states); and

(3) Conditional data, which is a recording of data depending on vehicle usage over time.

A further class of data that could be incorporated is infrastructure data, which includes track type, track geometry (such as curve, radius of curve, straight, switch, crossing, gradient) and signals (such as signal location, strength, status and type). Each of these classes is also complex by nature and contains correlated sub-classes. An event data record will contain data including (but not limited to) some or all of: A serial reference number A date and time stamp of the appearance and disappearance of the event

Event class Event description ^• System, sub-system or component in which the event appeared Geographical location of the vehicle at the time of the event Vehicle and/or component identification number in which the event appeared

The associated environment data record will contain data including (but not limited to) some or all of:

Calculated statas (i.e. output from a virtual sensor) State of the traction system, e.g. in braking or motoring mode, acceleration or brake setting, source and type of power (for multi-system vehicles)

Condition of the traction system, e.g. frequency of the generator, power output, current and voltage in the electrical propulsion motors, overhead line voltage State of other on-board equipment or components, e.g. air conditioning Mechanical condition of other on-board systems, e.g. air pressure in the brake system, vibration frequency of rotating components (shafts, gears, bearings etc.), torque and power applied, component measurements (location, length, twist, bend etc.), temperature of various components, pressure either side of a filter (air or liquid) Electrical condition of on-board systems, e.g. electrical power drawn / used at various points, current, voltage, resistance, inductance, impedance, irregularity of current (such as from fiash-oyers)

Fluid analysis, e.g. air, hydraulic oil and lubrication oil cleanliness Train data, e.g. speed, acceleration, deceleration The associated conditional data record contains fields with frain state data including (but not limited to) some or all of: Load weight

Weight in the relevant car(s) Vehicle identification number

Component / assembly / sub-assembly identification details Date and time stamp Geographical position

Input, calculated or otherwise derived threshold value against which the measurement is made

Time based logs, e.g. time at stations, time for which doors are open / closed / operation, time under power / braking / cruising / stationary.

Quantity based logs, e.g. number of operations of doors, pantographs, third rail shoes, auto-couplers, brakes. Distance based logs, e.g. distance covered, distance under power / braking / cruising / stationary

Supplementary data may also include:

External and internal temperatare Infrastructure temperature (e.g. rails may be much hotter than the air temperatare)

External and internal humidity Rainy or flooded conditions

On-board comparisons are made and reported against thresholds, including (but not limited to) some or all of:

Power drawn (and/or torque) versus acceleration, to identify power losses and inefficiencies

Pressure either side of a filtration device, to identify clogged filters Passenger compartment temperature, external temperatare and power drawn by the heating or air conditioning system, to identify faults in those systems; these may also be correlated with the proportion of the journey for which the doors are open Wheel slippage versus track geometry and track wetness (rainy or flooded conditions) to identify problem areas of track for traction

Braking force applied versus speed of deceleration, load weight (and possibly track gradient), to identify braking efficiency and braking system problems .

Twist in shafts versus power and/or torque applied, to identify deterioration in shafts

Frequency of vibrations versus vehicle speed and/or component rotational speed, to identify problems in shafts, gears, bearings etc.

Vibrations and/or accelerations in any direction other than the direction of travel of the vehicle, against track geometry and/or location of the vehicle, to identify track condition

Signaling or radio signal strength against location, to identify problems in signaling or radio systems

Engine / gearbox / bearing / shaft vibrations versus distance under power, to identify accelerated deterioration in engine / gearbox / bearing / shaft condition Voltages at different points in circuits, and also versus actuation signals (from virtual sensors in the vehicle control system), to identify short circuits

Power / braking force requested (from virtual sensors in the vehicle control system) versus power / braking force sμpplied by motors / brakes etc., to identify problems in power / braking systems

The organisation and types of the fields in the data sub-types can vary within the same monitoring system depending on the system(s) being monitored. Thus the vehicle sends the data most appropriate for a given situation and parameter / component / assembly being monitored. For example, the system sends data relating to the electrical environment when data relating to electrical systems condition is being stored or fransmitted. hi a second example, it sends data relating to the air system environment when data relating to the air system is being stored or transmitted. This can be done within the same monitoring system, between software versions of the off-board system (which allows for modification or addition of monitoring systems), and between different monitoring system (radically different vehicles have different needs in monitored values).

Having determined the priority of the data, the data communication system may optionally select between 2 or more different methods of handling communications (such as cellphone, satellite transmission and wireless LAN) with remote vehicles according to the priority of data to be transmitted. High priority data includes:

Communications following alarm conditions, that are reported in real-time or near-real-time;

Communications on a regular scheduled download; and Real-time or near-real-time interrogations of on-board systems initiated off- board.

Low priority data includes:

Download of trip and/or background data; Non-urgent data, not reaching alarm conditions; Software, bug fixes, software upgrades; and

Parameters and settings, and updates of parameters and settings.

For low-priority data, the data exchange process is limited to sending batches of data containing event, environment and/or condition types information. The link used in this embodiment for live communications is a GSM link (Global System for Mobile communication), using its data and/or SMS (Short Messaging Service) channel using protocols well known in the field. The data channel is used when reliable network connections are known to be available from the network provider (long data transfers can be very sensitive to the network quality because of the time the communication lasts, since long messages are more likely to be broken during the data transfer). The SMS channel is used as an alternative when there is known shortcomings in the quality of the network (bad reception areas, obstacles on the line such as bridges, tunnels). It allows sending a batch of data packet by packet and does not necessitate establishment of a connection for a long period of time.

The exchanges of data between the on and off-board systems can be scheduled or spontaneous. A scheduled exchange will normally be initiated by the off-board system, which holds schedule details (date and time, cycles of vehicles to contact, and details of vehicle including primary and secondary phone numbers). When an upload is due, details are taken and the vehicle is contacted with a request for data as shown in Figure 27. A request can be originated from the external off-board system 1 and transmitted 2 to the vehicle onboard system, or can be generated by the on-board system 3 itself. Once the request has arrived, the data is collected 4 and, depending of the state of the wireless connection (is it still connected 5, and is it an transmission means appropriate for transmitting bulk data 7), either the data is simply send back on the same connection 8 or a call to the off-board system is re-initiated and data sent through that connection 6. Such a request can be for one, more than one, or all types of data (event data, environmental data, condition data etc.). The vehicle has then the option to reply within the same request call or can call back the off- board communication system with the requested data. This can be arranged such that if any call is broken (for example, by poor network coverage), the on-board systems then initiate the re-connection.

In one type of "live" (real-time or near-real-time) exchange, the vehicle takes the initiative to call the off-board system for transferring some important data as shown in Figure 28A. As soon as a high priority (alarm) event is raised 1, data is collected 2. The on-board system verifies whether or not there is a data transmission channel currently open 3. If there is one open, it is interrupted to send data 5; if not, a connection is made to the off-board system is made 4 for the data to be transmitted 5. An alternative set-up, as depicted in Figure 28B would be for the system to verify 6 whether or not the open data transmission channel is the channel that would normally be used for fransmission of alarm / high priority data. If it is, then the new alarm condition is added to the end of the current transmission without interrupting it 7. If not, then the system opens a transmission channel appropriate for urgent data 4, so that the current fransmission on bulk data channels can continue uninterrupted. This data is normally of event type containing environment parts and is sent when special "alarm" conditions are met on the vehicle (high priority malfunction or threshold-breaking reporting event). The data exchanged includes the alarm, statas data directly related to the alarm condition, vehicle and system data and, optionally, supporting data such as environmental data and status data from related systems and sensors

In a second type of live exchange, an off-board person (such as a vehicle or fleet manager or engineer) interrogates on-board systems in real-time or near-real-time during the investigation of an issue or for another reason that requires data to be made available before the higher-priority data download, as shown in Figure 29. The message from the off-board system is fransmitted to the on-board system 1, on receipt of which the on-board diagnostic system collects the data 2 and sends it back 3 during the same fransmission. This will normally be performed using a high priority (alarm) data link 4, in this case radio fransmission.

In a third type of live exchange, the off-board system interrogates the on-board system (for example, on a scheduled download initiated by the off-board system) for updates of the condition of the vehicle or of specified assemblies, systems or components on the vehicle, as shown in Figure 30. A message 1 will be sent to the on-board system from the off board system. The on-board system will then collect the data from the component 2 and return the data 3. In this case, differing from Figure 29, because it is a scheduled download initiated off-board, the transmission means will normally be selected according to the same criteria as for a scheduled fransmission initiated by the on-board system 4. This may be performed, in one example, by the off-board system interrogating the appropriate on-board systems, assemblies or components through the on-board processor, hi a second example, the onboard system maintains a registry of current data from the appropriate systems, assemblies or components; when interrogated by the off-board system, the on-board system downloads some or all of the contents of this registry. In a third system, the off-board system interrogates the main on-board store to obtain the requisite information.

For higher priority data, the communication exchange is more refined. In this embodiment the off-board and on-board systems are part of a private wireless network using TCP/IP (Transport Control Packet / Internet Protocol) as the underlying protocol, though other protocols may be used. The participants are identified by their IP addresses. This gives the possibility that any node in the network can communicate with another. However this is restricted and on-board system nodes communicate only with the off-board system node. The wireless network is implemented both through GSM and IEE 802.1 IB type connection.

GSM is the slow connection and is used when only this type of connectivity is available: on the main line, ex-depot. IEE (Institute Of Electrical Engineers) 802.1 IB is the fast connection, allowing a greater throughput, and is used when accessible, in locations where base transponders are installed. The switching from one type of communication to another is made automatically with priority for high-speed connections.

As shown in Figure 31, a further type of data fransmitted is complex messages which can transport different kinds of information. Each message consists of a command and associated data and has an associated response. The set of commands and responses can be enriched as new services are developed. This allows not only for fransfer of stored diagnostic and live data from the vehicle to the data storage system, but also for the fransfer of configuration data, parameters, software bug fixes and upgrades, and other data to the vehicle. The connection between the two systems (on-board and off-board) does not have to be terminated at the end of a exchange, but can be kept live indefinitely. Both on-board and off-board systems can initiate such communications depending on their needs. Figure 31 shows how data is formatted for two types of data. First an incoming request arrives at the on-board system 1. If the request is for event, condition or environmental data 2, the data is first formatted 4 before being passed on to the fransmission module. If the request is for other data 3 such as current release of software, copies of parameters and settings, or hardware configuration data, the data also needs to be collected and formatted for transmission 5 prior to passing to the transmission module. At the fransmission module 6 the system initiates a call 7 to the ground station. If the connection is established 8, the requested data is sent 9. If not, the system tries again to establish the connection, repeatedly if necessary 10). If the initial request is for no known data format, or cannot be met, or if the system fails connection 10 times to make a, then a notice of failed transmission 11 appropriate to the reason for the failure is stored in the fransmission module for sending to the off-board system during the next successful transmission.

An interactive diagnostic service allows users to view live diagnostic faults on the vehicle without first uploading them to the data storage, and to look for related symptoms and causes on related systems (i.e. nearby, or interconnected, systems). An interactive data process service enables users to monitor process data (e.g. sensor values, control system data, settings and parameters in operation, real-time observation of the execution of programmes and of the results and effects of executing those programmes) remotely. A train overview service allows the train configuration (which vehicles, assemblies, sub-assemblies and components are on the frain, and the make, model, modification state, time or mileage etc. since last overhaul, age and other relevant data) to be obtained. A code download service allows new services to be transferred to the on-board system or existing ones to be updated.

The above description has described various embodiments of a diagnostic system within the scope of the invention. It should be noted that the embodiments described above are susceptible to various modifications and alternative forms. For example, the diagnostic system could be applied to monitoring a building. In this context, the elements described as "on-board" are within the building being monitored and "off-board" elements are elsewhere. Monitored elements may include temperatare, air quality, air conditioning, intruder and fire alarms, CCTV, IT and telephone systems, lifts, heating, lighting, fuses / circuit breakers, personnel clocking systems, security staff monitoring machines (to ensure that they do the complete tour of the premises every so often) and any other appropriate building equipment or systems. By adding still more sensors one could detect whether windows are left open at night, when the building is vacated; movement sensors in sensitive areas; water and drainage systems and other relevant measurements. Such a system enables a variety of buildings to be monitored from one central location; it would be equally applicable to a company with many premises (such as retail outlets or multiple warehouses or factories) and to a building management company monitoring third parties' premises in a manner much more comprehensive than current security monitoring services:

If the diagnostic system is embodied in a machine shop, each monitored "vehicle" could be a machine, wherein "on-board" denotes within the machine being monitored and "off-board" is elsewhere. These can vary between simple and extremely complex machines. The more complex machines have multiple monitoring systems on board such as tool breakage sensors, fault detection software, overload detectors and logs of hours of operation of the machine. To these further sensors can be added, for identifying where people are or are not, total power consumption, performance of swarf conveyors (to detect blockages), weight of swarf bins (to know when they need emptying), volume and cleanliness of coolant, and other appropriate conditions. This enables an entire machine shop to be monitored from one location, such as the supervisor's office, enabling the use of manpower and effort to be optimised in monitoring each machine and reducing down time. Such a system would be particularly helpful if the machines are distributed in different locations about a site.

If the diagnostic system is embodied in an oil rig, each monitored "vehicle" could be a machine, system or accommodation section within the rig or sub-surface installations and devices associated with the rig or surface installations associated with the rig such as loading and anchorage buoys, wherein "on-board" denotes within the machine, system or section being monitored and "off-board" is elsewhere. Alternatively, the rig itself may be monitored remotely, in which case "vehicle" is the rig and anything on the rig; "on-board" means on or relating to the rig and its associated installations and systems, and "off-board" means elsewhere.

If the "vehicle" is a pumping or relay station (relaying power, radio signals, microwave transmissions, fibre-optic signals etc.), "on-board" means within or associated with the station being monitored; "off-board" is elsewhere. Monitored elements of a pumping station would include but not be limited to power drawn, pressures at various points, leakage detection, intruder detection and monitoring of the pumping apparatus itself. Monitored elements of a relay station would include but not be limited to detection of signal strength (voltage, frequency, current, signal coherence etc.) at various points, power consumed, wind speed, weight of snow and ice forming on sensitive parts of the installation, and intruder detection.

Many modifications in addition to those described above may be made to the structures and techniques described herein without departing from the scope of the invention. Accordingly, although specific embodiments have been described, these are examples only and are not limiting upon the scope of the invention.

Claims

CLATMS

1. A diagnostic apparatas for monitoring a vehicle comprising a plurality of monitored components, the diagnostic apparatus comprising: a plurality of sensors for generating measured data relating to the operation of the monitored components; one or more sensors for generating environmental data relating to the current operating environment of the monitored components; pre-processing means for receiving the measured data and environmental data from the sensors and analysing the data to determine if the data is reportable; data processing means for receiving the data from the pre-processing means and correlating at least a portion of the data from one or more sensors with data or derived data from one or more other sensors to generate condition data relating to the condition of the vehicle; and. data transmission means for transferring at least a portion of the condition data to a data processing system external to the vehicle.

2. The diagnostic apparatas of claim 1, wherein the vehicle is a train having a plurality of cars, two or more of the cars having a data processing means for receiving measured data and generating condition data relating to monitored components in the respective cars, the two or more cars also having data transmission means, the data processing means for each car communicating at least a portion of the condition data to the other data processing means in the train and coordinating fransfer of data to the external data processing system through the data transmission means.

3. The diagnostic apparatus of claim 1 or 2, wherein the environmental data includes data relating to the ambient environment of the vehicle.

4. The diagnostic apparatas of claim 2, wherein data is transmitted between two or more of the cars for one or more operations to be performed on the data.

5. The diagnostic apparatas of any of the preceding claims, wherein the pre-processing means only communicates the measured data to the data processing means if the data is reportable.

6. The diagnostic apparatas of claim 5, wherein the data processing means further comprises local storage means for receiving and storing data from the pre-processing means.

7. The diagnostic apparatus of any of the preceding claims, wherein a footprint is stored relating to one or more of the monitored components or the vehicle, the footprint comprising: data identifying the normal operation of the component or the vehicle; data relating to acceptable variances in the normal operation data; and multiple recorded thresholds relating to one or more levels of reportable conditions, which thresholds may or may not relate to alarm conditions.

8. The diagnostic apparatus of any of the preceding claims, wherein a footprint is stored relating to one or more of the monitored components or the vehicle, the footprint comprising: data identifying the normal operation of the component or the vehicle; data relating to acceptable variances in the normal operation data; and one or more dynamic thresholds relating to one or more levels of reportable conditions, the dynamic thresholds varying according to the measured data or environmental data from one or more other sensors.

9. The diagnostic apparatas of claims 7 or 8, wherein the footprint includes data relating to how much data is to be stored by the diagnostic apparatas for later transfer to the external data processing system.

10. The diagnostic apparatas of any of the preceding claims, wherein a footprint is stored relating to one or more of the monitored components or the vehicle, the footprint storing data relating to how much data is to be stored by the diagnostic apparatas before or after the occurrence of a reportable condition for later transfer to the external data processing system.

11. The diagnostic apparatas of any of the preceding claims, wherein a footprint is stored relating to one or more of the monitored components or the vehicle, the footprint comprising data relating to additional sensors or systems to be polled as a result of detection of one of more reportable conditions.

12. The diagnostic apparatas of any of the preceding claims, wherein a footprint is stored relating to one or more of the monitored components or the vehicle, the footprint comprising data relating to pre-processing or processing of measured data to be performed as a result of detection of one or more reportable conditions.

13. The diagnostic apparatas of any of claims 7-12, wherein the pre-processing means: communicates the measured data to the data processing means if the measured data is reportable; communicates the measured data to a local storage means if the measured data is identified for retention by the footprint data; and erases the measured data if the measured data is not reportable or not specified for retention.

14. The diagnostic apparatas of claim 13, wherein the pre-processing means communicates measured data from one or more sensors to the data processing means if measured data from one or more other sensors is reportable.

15. The diagnostic apparatus of any of the preceding claims, further comprising one or more virtual sensors for generating virtual measured data representing calculated physical values, the virtual measured data generated from inputs comprising measured data from one or more sensors or external systems.

16. The diagnostic apparatas of any of the preceding claims, wherein the data processing means compares measured data from one or more sensors with one or more dynamic thresholds to determine if the data is reportable, the thresholds varying according to the measured data from other sensors or environmental data.

17. The diagnostic apparatas of any of the preceding claims, wherein the data processing means generates fault or alarm data derived by comparing measured data from one or more sensors to one or more dynamic thresholds varying according to the measured data from other sensors or environmental data.

18. The diagnostic apparatas of any of the preceding claims, wherein the data processing means calculates predictive data related to a predicted physical condition for one or more components of the vehicle determined with reference to the condition data.

19. The diagnostic apparatas of any of the preceding claims, wherein the diagnostic apparatas comprises data storage means and wherein transfer of data by the data fransmission means to the external data processing system is made in response to a status of the data storage means.

20. The diagnostic apparatas of any of the preceding claims, wherein the fransfer of data by the data fransmission means to the external data processing system is made at predetermined points along a route followed by the vehicle.

21. The diagnostic apparatas of any of the preceding claims, wherein the data transmission means comprises: two or more communications means for broadcasting data for transfer of the data to the external data processing system, each communications means broadcasting data according to a different fransmission standard; and means for automatically selecting the communications means to be used for transferring a selected portion of the data, the selection being made with reference to at least one of the criteria comprising priority of the data fransfer, quantity of data to be transfened, and location of the communications means in relation to equipment for receiving the broadcast.

22. The diagnostic apparatus of any of the preceding claims, wherein: one or more of the sensors generate measured data relating to vibrations, the measured data including amplitude of the vibrations; and the data processing means receives the vibration data, analyses the data over a time period to generate data relating to frequency of the vibrations, compares the vibration amplitude and frequency data to footprint data comprising vibration frequency and amplitade data characteristic of one or more predetermined conditions, and generates an output indicating occmrence of one or more of the predetermined conditions if the vibration data matches the footprint data.

23. The diagnostic apparatas of any of the preceding claims, wherein: one or more of the sensors generate measured data relating to sfress or torque of a rotating shaft, the measured data including amplitade of the stress or torque; and the data processing means receives the measured data, analyses the data over a time period to generate data relating to variations in the amplitade, frequency or phase of the data, comparing the generated data with amplitade, frequency or phase data characteristic of one or more predetermined conditions, and generates an output indicating occurrence of one or more of the predetermined conditions as a result of the comparison with the characteristic data.

24. The diagnostic apparatas of claim 23, wherein one or more of the predetermined conditions relate to systems or components external to the shaft.

25. The diagnostic apparatas of any of the preceding claims, wherein: one or more of the sensors generate measured motor data relating to electrical current drawn by or voltage across a motor, the measured motor data including amplitade of the electrical current or voltage; and the data processing means receives the measured motor data, analyses the data over a time period to generate data relating to variations in the amplitade, frequency or phase of the data, compares the generated data with footprint data comprising amplitade, frequency or phase data characteristic of one or more predetermined conditions, and generates an output indicating occurrence of one or more of the predetermined conditions as a result of the comparison with the footprint data.

26. The diagnostic apparatas of claim 25, wherein one or more of the predetermined conditions relate to systems or components external to the motor.

27. The diagnostic apparatas of any of the preceding claims, wherein: one or more of the sensors generate measured data relating to temperatare inside an area whose temperatare is controlled by an environmental control system, the inside of the area being separated from the outside of the area by one or more doors; one or more of the sensors generate measured data relating to temperatare outside the area; and the data processing means receives the inside and outside temperatare data and data relating to time each door is opened, calculates a dynamic threshold based on the inside and outside temperatare data, the door opening data and cooling curve of the environmental control system, compares the inside temperatare data to the dynamic threshold, and generates an output indicating a fault condition if the inside temperatare data is less than the dynamic threshold.

28. A method for monitoring a vehicle having a plurality of monitored components, the method comprising: collecting measured data relating to the operation of the monitored components from a plurality of sensors; collecting environmental data relating to the current operating environment of the vehicle from one or more sensors; pre-processing on board the vehicle the measured data and environmental data from the sensors to determine if the data is reportable; correlating on board the vehicle at least a portion of the data to generate condition data relating to the condition of the vehicle; storing at least a portion of the condition data on board the vehicle; and transmitting at least a portion of the condition data to a data processing system external to the vehicle.

29. The method of claim 28, wherein the vehicle is a train having a plurality of cars, the method further comprising: providing two or more of the cars with data processing means for receiving measured data and generating condition data relating to monitored components in the respective cars; communicating at least a portion of the condition data between two or more of the cars; and coordinating transfer of at least a portion of the condition data to the external data processing system through a data transmission means.

3.0. The method of claim 28 or 29, wherein the environmental data includes data relating to the ambient environment of the vehicle.

31. The method of claim 28, wherein data is fransmitted between two or more of the cars for one or more operations to be performed on the data.

32. The method of any of claims 28-31, wherein only measured data that is reportable is conelated.

33. The method of any of claims 28-32, further comprising storing the pre-processed data in one or more local storage means on board the vehicle.

34. The method of any of claims 28-33, further comprising storing a footprint relating to one or more of the monitored components or the vehicle, the footprint comprising: data identifying the normal operation of the components or the vehicle; data relating to acceptable variances in the normal operation data; and multiple recorded thresholds relating to one or more levels of reportable conditions, which thresholds may or may not relate to alarm conditions.

35. The method of any of claims 28-34, further comprising storing a footprint relating to one or more of the monitored components or the vehicle, the footprint comprising: data identifying the normal operation of the component or the vehicle; data relating to acceptable variances in the normal operation data; and one or more dynamic thresholds relating to one or more levels of reportable conditions, the dynamic thresholds varying according to the measured data or environmental data from one or more other sensors.

36. The method of claims 34 or 35, wherein the footprint includes data relating to how much data is to be stored on board the vehicle for later transmission to the external data processing system.

37. The method of any of claims 28-36, further comprising a step of storing a footprint relating to one or more of the monitored components or the vehicle, the footprint including data relating to how much data is to be stored on board the vehicle before or after the occunence of a reportable condition for later fransmission to the external data processing system.

38. The method of any of claims 28-37, further comprising a step of storing a footprint relating to one or more of the monitored components or the vehicle, the footprint including data relating, to additional sensors or systems to be polled as a result of detection of one or more reportable conditions.

39. The method of any of claims 28-36, further comprising a step of storing a footprint relating to one or more of the monitored components or the vehicle, the footprint including data relating to pre-processing or processing of measured data to be performed as a result of detection of one or more reportable conditions.

40. The method of claim 33, further comprising: storing a footprint relating to one or more of the monitored components or the vehicle, the footprint including data specifying measured data to retain in the local storage; and erasing the measured data if the measured data is not reportable or not specified for retention; and wherein the measured data is correlated only if the measured data is reportable and the measured data is stored in the local storage means only if the measured data is identified for retention by the footprint data.

41. The method of any of claims 28-40, further comprising generating virtual measured data representing calculated physical values, the virtual measured data generated from inputs comprising measured data from one or more of the sensors or external systems.

42. The method of any of claims 28-41, wherein the pre-processing step comprises comparing measured data from one or more of the sensors with one or more dynamic thresholds to determine if the data is reportable, the thresholds varying according to the measured data from other sensors or environmental data.

43. The method of any of claims 28-42, further comprising generating fault or alarm data on board the vehicle derived by comparing measured data from one or more of the sensors to one or more dynamic thresholds varying according to the measured data from other sensors or environmental data.

44. The method of any of claims 28-43, further comprising calculating on board the vehicle predictive data related to a predicted physical condition for one or more components of the vehicle determined with reference to the condition data.

45. The method of any of claims 28-44, the fransmission of condition data to the external data processing system is made in response to a status of the storage on board the vehicle of the condition data.

46. The method of any of claims 28-45, wherein the transmission of data to the external data processing system is made at predetermined points along a route followed by the vehicle.

47. The method of any of claims 28-46, wherein the transmitting step condition data to the external data processing system comprises automatically selecting between two or more different transmission standards for transmitting a selected portion of the data, the selection being made with reference to at least one of the criteria consisting of priority of the data fransfer, quantity of data to be transferred, and location of the vehicle in relation to equipment for receiving the broadcast.

48. The method of any of claims 28-47, wherein: the step of collecting measured data comprises collecting measured data relating to vibrations or one or more of the monitored components, the measured data including amplitade of the vibrations; the step of correlating comprises analysing the data over a time period to generate data relating to frequency of the vibrations and comparing the vibration amplitude and frequency data to footprint data comprising vibration frequency and amplitude data characteristic of one or more predetermined conditions; and further comprising the step of generating an output indicating occurrence of one or more of the predetermined conditions if the vibration data matches the footprint data.

49. The method of any of claims 28-48, wherein: the step of collecting measured data comprises collecting measured data relating to sfress or torque of a rotating shaft, the measured data including amplitade of the stress or torque; the step of correlating comprises analysing the data over a time period to generate data relating to variations in the amplitade, frequency or phase of the data, comparing the generated data with amplitude, frequency or phase data characteristic of one or more predetermined conditions; and the method further comprises the step of generating an output indicating occurrence of one or more of the predetermined conditions as a result of the comparison with the characteristic data.

50. The method of claim 49, wherein one or more of the predetermined conditions relate to systems or components external to the shaft.

51. The method of any of claims 28-50, wherein: the step of collecting measured data comprises collecting motor data relating to electrical current drawn by or voltage across a motor, the measured motor data including amplitade of the electrical current or voltage; the step of conelating comprises analysing the data over a time period to generate data relating to variations in the amplitade, frequency or phase of the data, compares the generated data with footprint data comprising amplitude, frequency or phase data characteristic of one or more predetermined conditions; and the method further comprises the step of generating an output indicating occurrence of one or more of the predetermined conditions as a result of the comparison with the footprint data.

52. The method of claim 51, wherein one or more of the predetermined conditions relate to systems or components external to the motor.

53. The method of any of claims 28-52, wherein: the step of collecting measured data comprises collecting measured data relating to temperature inside an area whose temperatare is controlled by an environmental control system, the inside of the area being separated from the outside of the area by one or more doors; the step of collecting measured data further comprises collecting measured data relating to temperatare outside the area; the step of conelating comprises calculating a dynamic threshold based on the inside and outside temperatare data, data relating to the time each door is open and a cooling curve of the environmental control system, and comparing the inside temperatare data to the dynamic threshold; and the method further comprises the step of generating an output indicating a fault condition if the inside temperatare data is less than the dynamic threshold.