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

  • To use an array of sensors to monitor all relevant parameters, in order to provide advanced warning of degradation prior to points failure;
  • To provide, in the event of a catastrophic failure, theimmediate past history to identify the cause;
  • To provide continuous monitoring, as a supplement to scheduled examinations by maintenance personnel;
  • To provide on-line accurate measurement, e.g. of position and load force data, to support maintenance action (e.g. adjusting mechanical alignment);
  • To provide an automated archival record from which broad trends can be extracted from the entire railway asset base.

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 positions of the stock and moving rails, lock and detector blades and the position of the points machine itself are relative to a fixed reference beam.
  • The temperatures of both the points machine and rail are monitored to allow thermal expansion and contraction to be considered when measuring changes.
  • Discrete signals are provided to monitor case opening and closing as well as hand-crank insertion and removal. These can be used to provide automated records of maintenance action for management, and for field support for maintenance engineers.
  • The motor voltage and current and load force are also measured and, together with the dynamic switch rail position, provide comprehensive data on the points machine movement.

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:

  • Points machine movement (a movement event) - when the points machine is activated, data load force and switch rail position data is collected at high speed to capture the features of the movement;
  • Background data - all of the sensors (excluding the motor current and voltage which by definition should be nominally zero) provide useful data on the behaviour of the points machine in stasis.
  • Passage of a train over the points (a train event) - specialised procedures have been developed to detect and record train events, as evidence suggests they are important in explaining points behaviour.
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:

  • The cost of site access is high, both for installation and for subsequent modifications;
  • Site access involves a degree of risk to personel due to trains;
  • There is little data available to model the behaviour of the points layout, particularly during train transits and in faulty conditions

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:

  • Simple alarms are provided based on high or low values on any of the monitored parameters (or parameters calculated from movement or train events). This allows simple, 'shallow' reasoning to detect undesirable conditions. For example, if the stock rail has moved from its calibrated zero by more than 2mm (say), then this is inherently undesirable and an alarm can be raised. Here the effect of the fault is detected - a shift in the stock rail - even though the underlying cause is uncertain.
  • Based on experiment and field experience, 'deep' knowledge is being developed to diagnose specific important fault types (e.g. high slide chair friction) based on the behaviour of several parameters. For example, figs. 4 and 5 show points machine reverse movement data for Chippenham and Melbourne respectively. Signal processing of the data sets provide various parameters values (e.g. peak force, peak current, duration of applied current, start of switch rail movement, switch rail movement duration). Values and trends are combined with expert knowledge to derive 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:


  • the degree of variation (for example its standard deviation)
  • the permanent, static shift in value that takes place as a result of the train transit.

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