Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Overview

Centrix stores analogue events for the electric current for DC Track Circuits and average current for AC Track Circuits.

The electric current is high when the track is not occupied and drops when the track is occupied:

 

Each of these occupations (clear - occupied - clear) can be considered as an occupation event; it can be thought of as a Centrix Capture event.

Centrix does analysis on the incoming data to try and locate these occupation events. This allows Centrix to show these occupations graphically to the user without requiring the user to manually zoom in and out on the analogue data. 

It also allows Centrix to show high level information about Track Circuit Assets such as number of occupations in the last time period (week / month / year etc.) and how many alarms have been raised as a fraction of total occupations in the last time period.

Implementation Details

The details of how Centrix builds occupation events are as follows:

  • Analogue Events come in to Centrix one by one.
  • If the analogue event channel is associated with a relevant asset (DC Track Circuit, AC Track Circuit, AF Track Circuit, Ebi Track Circuit) then Centrix will try to locate occupation events.
  • When the first event comes in, Centrix checks that there is sufficient historic data present to get an idea of what a typical occupation looks like. Currently, this check is just that there is at least one event yesterday and the day before yesterday. This should ensure that at least 24 hours worth of data is present. This check is cached for 24 hours and is therefore only checked and updated once per day.
  • If there is enough data, then Centrix analyses the last 24 hours worth of data to try and locate typical minimum and max values; in particular it is trying to find a sensible value to use above which, the track is clear and below which it is occupied. Half way between the min and max is used as this threshold value. This threshold value is only deemed sensible if the minimum is less than half of the maximum. Centrix expects the minimum to always be close to zero.
  • If this is the first event for the channel, it passes the above checks and a sensible threshold value is found, then a RailEventBuilder object is created for the asset. Each subsequent event is added to this builder. This builder handles the logic for deciding when an occupation starts and ends - using the threshold value that is given to it on creation. It also wraps the start and end of the occupation with some padding so that each event has a 'clear' zone either side of the 'occupied' zone.
  • The builder uses the threshold value to track each event it receives as the track being in a clear or occupied state. Until the first occupied event is received, the builder keeps a cache of 60 seconds worth of events. These events are used to populate the pre-occupation clear region.
  • Once the first occupied event is received, this pre-occupation clear region is locked and the builder starts to listen out for the next clear event which signifies the start of the post-occupation clear region.
  • Once the next occupied event is received, the builder locks this event as being completed and starts building the post-occupation clear region.
  • The post-occupation clear region is completed once 60 seconds worth of occupied data is received or the track goes back into the occupied state.
  • The occupation is saved as an asset, channel, start time and end time. This allows all of the events to be easily retrieved whenever an occupation event is required.
  • The builder is reset and starts collecting a cache of clear events again and listening for the first occupied event.
  • The cache for the typical threshold value per asset is reset after a week. So each week, new typical threshold values are found. If the asset is behaving well this value should change very little. 
  • System admins will monitor the number of occupation events being generated per asset and can disable this feature per asset. This is required to prevent huge amounts of nonsense occupations being created e.g. from misconfigured loggers. Site Admins can also do this; the feature can be disabled on a per asset basis using a checkbox on the asset edit page:

flow chart

Features and Limitations

Features and limitations of the current implementation:

  • When a new logger comes online, it won't start generating occupation events for at least a day.
  • Track Circuit flicks will count as an occupation event because there is no minimum time or number of events required for an occupied region.
  • If a misconfigured asset is fixed, it will take up to a week for sensible occupation events to be found. This is because the typical threshold value per asset is reset after a week.
  • If non track circuit data is assigned to a track circuit asset, the results will likely be garbage.
  • If the last days worth of data is nonsense for some reason or contains zero occupations, this will result in typical min and max values which are very similar. This could result in the algorithm trying to classify noise in the clear zone as occupations. This could create a huge number of nonsense occupations. Therefore, system admins have the ability to turn 
  • Channel associated to a track asset mid occupation - first occupation will be missed?
  • If no event is received between the last clear event and the start of the occupation, the occupation will not have a nice pre-occupation clear region.
  • In the future, Track circuit data coming in too frequently or garbage occupation events (e.g. nonsense channel / misconfigured logger) can be automatically blocked. At the moment however, it requires manual intervention to disable the feature for an asset.



  • No labels