Condition monitoring of railway points machine

Points machine diagram

The UTC research into developing on on-line condition monitoring system for railway points machine is based on a partnership between the University of Oxford and Westinghouse Signals in the UK and Australia. Using some of the techniques developed at Oxford for validating industrial instrumentation, the program has lead to the development of an industrial prototype (Westwatch) that has been tested on track in several locations in Australia.

The motivation for developing a railway points condition monitors can be summarized in

A typical electrically-operated points machine (Style 63), manufactured by Westinghouse Signals and widely used within the UK, was selected for analysis, on the basis that the manufacturer's expert knowledge was available. Points machine diagram - sensors

Based on a detailed analysis of the fault data provided, measurements were selected as shown in figure on the left.

The assumption is that if all of these measurements maintain an acceptable relationship with one another, then any form of mechanical misalignment of the points is unlikely.

There are two basic modes of operation for which data must be collected, while a third emerged during field trials:

Separate data records are kept for the two switch rail positions, or in the case of a movement event, which direction the switch rail is travelling. The terms 'Normal' and 'Reverse' are used to denote the different static states, while a 'Normal' movement moves to the Normal state.

The hardware description of the railway poitnts machine monitor can be found here

Dagnostics and alarms

The railway environment provides particular challenges for a condition monitoring system:

One important issue is to ensure that the condition monitoring system is flexible and can be configured remotely, thus minimising the need for site access. The UTC prototype systemt provides remote services such as http, ftp and telnet to enable effective management tools for both software and data, allowing for example the Australian sites to be monitored and upgraded from Oxford.

Two complementary mechanisms are provided to allow incremental improvements in alarms and diagnostics:

Several diagnostic algorithms have been developed and are now being field tested for robustness. As discussed at the end of the paper, thresholds, particularly for simple alarms, must be chosen based on as wide field experience as possible and, ideally, in consultation with maintenance staff.

When an alarm limit has been exceeded, a number of strategies can be used for informing higher level systems and/or maintenance staff that action is required. For example, WestWatch can send e-mails or SMS text messages to maintenance personnel. Trials have demonstrated that a mobile phone can receive a text message within 20 seconds of a fault condition occurring. Higher level monitoring software can take similar action if contact is lost with any WestWatch module (e.g. due to loss of power or communications). Points machine condition monitor web interface

Web Interface and Archival Records

The WestWatch system provides a Java-based Web interface to control and monitor its functionality. Remote or local users can access data and adjust configuration settings via a standard Web browser.

A key function of the WestWatch system is to provide a record of the behaviour of the points. The same database can be viewed in different ways according to the needs of the user.

For the purposes of maintenance management, different views of the same database are provided. Higher level monitoring software downloads data from each site on a daily basis and carries out off-line analysis to generate a permanent, archival record.

The resulting trends may be produced on several time-scales, e.g. day, week and month, and include alarm limits and time-stamped records of significant events (e.g. case opened/closed, alarm limit exceeded). A daily summary may be sent to relevant staff (e.g. maintenance managers) via email.











Train event example - Melbourne

Train events

It is a well-established principal of validation that faults are more readily observed when the system under scrutiny is undergoing stimulation, rather than when it rests in stasis. The most obvious example of system stimulation is when the points are thrown, and naturally all points condition monitoring systems are active when this happens. However, it must surely be the case that the passage of a train, with the corresponding huge injection of mechanical energy into the system, provides the greatest opportunity for testing the fastness of mechanical alignment.

On the left is a example of typical train event data recorded on a track in Melbourne. The train event is clearly visible in all of the displayed signals. The use of multiple sensors ensures that a train event can be correctly identified, reducing the risk of spurious noise on one sensor leading to the recording of a false train event.

Two basic properties that can be monitored for each parameter during a train event:

In this example, all measurements show the disturbance caused by the train, but the only significant shifts in value are for the detection rod and the switch rail, both of which move by about 0.2mm.

Data collected from other sites show that train data is very diverse. The Brisbane data shows a much longer train event of some 120s duration. Here the stock rail exhibits the largest shift, again by 0.2mm.

The example from Sydney shows much more significant shifts - a loss of load force of 15%, and movements in stock rail, lock and detection of 0.8mm, 0.5mm, and 2mm respectively. A 2mm shift caused by a single train transit might indeed be considered significant from a maintenance point of view, if detection failures are to be avoided.

These examples typify the variations observed in the points machine and its associated track during a train passage, which appear to depend upon the condition of the points machine and track, as well as the nature of the traffic (e.g. high/low speed, light electric passenger train, heavy goods diesel, etc). Train events can thus provide valuable extra information on how securely the mechanical system is fixed. It is a straightforward matter to provide alarms on the extent of such shifts, or the standard deviation ('extent of rattle') of the signals during a train transit. Trending may also be deployed to see how such parameters vary with time. The selection of threshold values, however, must be undertaken with care, as discussed below.
Train event example - Brisbane Train event example - Sydney

Train events can be a significant factor in explaining points behaviour. The example below shows the position of the detector rod in the reverse position over a 24 hour period at Melbourne, which experiences a series of jumps. Detction rod trend illustrating train effects

It has been confirmed, using the train detection algorithm, that each jump corresponds to a train event. It is evident that during peak traffic, there is a cumulative increase in position towards 2mm; later in the day with fewer trains the average position moves back towards 1mm. Of course, non-emergency maintenance action often takes place at periods of low train activity, such as at night. An examination of the detection rod alignment may reveal nothing amiss, only for a detection failure to occur during heavy traffic. Conversely, after a points failure, if there is any significant delay before maintenance occurs, then with further train events prevented, examination may result in a No Fault Found verdict.

High speed train data Train fast data colection - Melborune

The train transit data shown thus far is collected and analysed at 1Hz; this appears adequate for diagnosing conditions on the points machine and layout. However, higher speed data acquisition (140Hz) has also been used to provide more detailed information on the train impact, as illustrated in Figure 15, at the cost of much larger data files. Once again the sensor readings show strong correlation, in particular with regard to the timing of signal peaks and troughs, which correspond to the individual wheel axles of the passing train. More detailed analysis may yield the train speed and acceleration, and possibly the axle condition (e.g. the large spike seen on several sensors after 30s might be attributable to a flat wheel). This could considerably enhance the utility of the WestWatch system.

Train detection is a further demonstration of the flexibility of the WestWatch system. At the time of installation, no consideration had been given to using train events to provide diagnostic information. As its importance became clear from the field data, detection algorithms have been developed at Oxford and downloaded to the Australian sites. Clearly, password protection and version control systems are needed to ensure such procedures are secure and effective.