Nick Aschberger, Trackside Intelligence: Complexities of wayside detection equipment data management

Complexities of wayside detection equipment data

management Nick Aschberger

Software Development Manager

Commercial in Confidence

This is my first time speaking at a conference

So.

This will go one of two ways.



Niiiiiiiiiiiice


Here’s what we’ll talk about

1. A bit of background - introduction to wayside condition monitoring devices.

2. What the data is used for and why is this complex?

3. Simple software engineering approaches to handling this data and reducing error.


Wayside devices - background

A train goes by a wayside con-mon system.

Data for each component passing by (depending on the device type) is recorded.

Many different devices in heavy haul.

Data is used by maintenance planners.


Device timeline

1950/60s

HBDs & DEDs

1980s

WILD & WID

Hot/Cold Wheels

1990s

Bogie Geometry

2000s

RailBAM

Wheel Profile


HBD and DED


WILD


RailBAM


Wheel Profile


But Wait! There’s more! Bogie Geometry

Hi-Speed imaging and recognition (brake pads & shoes, couplers, wedges, etc)

Noise/Squeal (EPA)

Steak knives!


When planning maintenance?

Prioritization

Condition monitoring data

Existing work requests

Wagons that are maintained


So what’s so hard about that?

So you just incorporate some con-mon data into your maintenance

process.

Easy Peasy.


It’s not easy.

If it were easy, I would be unemployed and my children would

starve.



There are a number of reasons it’s not easy.

So let’s discuss.


#1 - Devices are all different

Each vendor supplies a system. Each vendor has different ways of retrieving and interpreting data.

The planner needs expertise in multiple systems. It takes hours (days) to interrogate and compile that data.


#2 – The data contains errors.

The “dirty secret” of condition monitoring devices.

Devices can make errors – resulting in errors in maintenance planning, or time is

spent compensating/analysing.


Errors come from many situations

HEAT

DUST

CALIBRATION

WEATHER

SUNLIGHT

(Birds, Snails, Plastic Bags)


The maintenance system too!

If you are doing the job of planning for rolling stock maintenance, then work

requests in the maintenance system are an input to this decision as well.

As are maintenance campaigns.

But the same problem exists! Data can be entered late, incorrectly or not at all.


#3 - Data association problems

All modern systems use AEI readers (vehicle AVI tags) to associate readings with

vehicles, axles and components.

But, this is not 100% fool-proof.

(Bad reads, Failed tags, Intermittent tags, Wrong programming)


AVI Tag Statistics

(Sample data aggregated over our heavy haul customers)

Total AVI tag read attempts 25,603,252

Total missed AVI tag reads 1,296,702 or 5.06 %

Total missed due to

failed/missing tags on vehicles

1,117,062 or 4.36 %

Total missed due to other

reasons (tag reader failure,

environment)

179,640 or 0.7%.


#4 – How to choose one job over another?

Which is worse?

(Example)

1.A medium level wheel flat alert, or

2.Two low level acoustic bearing faults alerts?

Unfortunately we can’t tell you this!

And it changes over time anyway!


The NET effect?

If you’re not making optimal decisions, then you’re either:

• Over-maintaining: Extra cost

• Under-maintaining: Increasing production delay risk


OK, then.


It’s not so bad

For 80% of decisions, things work pretty well, without even thinking

about this stuff.

But… we need to be better than that.


It’s not so bad

For 80% of decisions, things work pretty well, without even thinking

about this stuff.

But… we need to be better than that.


Simple software engineering concepts

We can apply some well known and reasonably straight forward software engineering concepts to this problem.

But be aware there is “No silver bullet”. (Fred Brooks, 1986, No Silver Bullet — Essence and Accidents of

Software Engineering)


Get everything in one place

The first (obvious?) thing to do is to get everything in one place – condition monitoring and maintenance data.

This removes the expensive effort performed by the planner.

NOTE: That database will have a HUGE amount of data in it.


Data warehousing

A specific structure of database to:

Handle big data (a lot of history).

Doesn’t need to be used for real time alerting.

Optimized for big queries over large data sets, not individual transactions.


Data warehousing Transactional (Traditional)

Database Data warehouse

Data sources

Operations, Users, Transactions

Other databases & systems

Purpose To control/capture data transactions as they happen

To consolidate data for

analysis and reporting over time

Features

& Structure

Optimized for transaction

processing.

Fast inserts/updates per

transaction.

Normalized structure.

Fewer database indexes.

Optimized for querying &

reporting.

Faster queries, over larger

sets of data

De-normalized structure.

More database indexes.


Just doing this 1. Reduction in effort – just consolidating

the data in one spot saves ~50% of the planners time.

2. Much more complex queries can be defined, specific for each business need.

3. Historical repository for analysis.


Data cleansing. Just chuck it out.

Another (obvious?) technique.

We have lots of data anyway.

Per-instrument rules applied.

This applies to maintenance data too!


Example – removing a wheel profile error


Rates of data removed Device type # Train reads

# invalid train reads

% invalid train reads

Laser wheel profile

3399 417 12.2%

RailBAM 11010 0 0%

Wheel Impact Load detector

7315 3 0.04%

Hot Box Detector

3497 21 0.6%

*Laser devices are heavily effected by dust and sunlight in heavy haul *RailBAM cleans its own data


Total Records 27062

Records deleted as invalid

entries by a user

(open for a period of time)

462 1.7%

Records in an invalid state 493 1.82%

Records that are in a “work

started” state for more than

6 weeks

44 0.16%

Records requesting work

that is already in the system

(duplicates)

1901 7%.

Maintenance data errors


Trend based decisions Now we leverage the power of the

consolidated data warehouse.

To make informed decisions no individual measurement can be relied on.

Tools that facilitate trending are built on top of the warehouse.


Trending tools Simple:

• Counts of events

• Database queries that aggregate information for each component

• Running scores that are calculated by the warehouse

• Visualisation tools, where required.


Trend graph example


Conclusions (1) 1. Simple (but not easy) software techniques

can be applied to give us higher confidence in our decision making.

2. Build a data warehouse containing both condition monitoring data and maintenance information.

3. The presence alone of the data warehouse itself greatly reduces time spent in maintenance planning.


Conclusions (2) 4. Apply the principles of Data Cleansing,

and Trending of measurements to the warehouse, to significantly reduce errors in maintenance planning.

5. This in turn reduces cost:

• Reduction in over-maintenance, or

• Reduction in production delay risk.


We made it

Business

Nick Aschberger, Trackside Intelligence: Complexities of wayside detection equipment data management