Page Comparison

...

Centrix stores analogue events for the electric current for DC Track Circuits and average current for AC Audio Frequency 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 being similar to 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. 

Image Removed

It also allows The 'Typical Behaviour' line shows the average clear and occupied values over the last 30 days. Overlayed on top of this is a specific occupation event.

Image Added

Note: When displaying this data on these graphs, Centrix shows both clear regions as 25 percent of the length of the occupied region. This is so that all occupations should look similar to the user and ensure that they are easy to view and interpret.

Creating occupation events can allow Centrix to show high level information about Track Circuit Assets such as the 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.

If an asset has no track circuit occupations, then this typical behaviour graph reverts to its old behaviour where it retrieves shows only the typical minimum and maximum values and plots this them against the alarm thresholds. The dashed line shows the most recent value. This should adapt depending on whether it has rail events in the relevant time range ?

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 and create 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 one event 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 maximum 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 minimum and max maximum 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 (60 seconds) 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 keep of whether the track being circuit is 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 statefor the current analogue event.
• One the track goes back into the clear state, the occupation is saved with an end clear time padding of 60 seconds.
  • 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 next occupied event.
• Occupation events are not allowed to overlap. The RailEventBuilder is in charge of ensuring this is respected.
• The cache for the typical threshold value per asset is reset after a weekevery 7 days. 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:

  

...

• 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. This should be beneficial and simplify alarm analysis on this data.
• 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 and many invalid occupation events may be created.
• 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  
• If a channel is associated to a track asset mid occupation - , the 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.

The 24 hour cache is based on real time not event time!

Flow Chart