Software Architecture for Condition Monitoring of Mobile Underground Mining MachineryPresented by: Dr. Markus Timusk, P.Eng.

Paper by: Jordan McBain, P.Eng. and Dr. Markus Timusk, P.Eng.

1

2

Overview

• Problem:

• Diversity of automated condition monitoring applications

• Requires a diversity of signal processing and decision-making algorithms

• No singular technique suitable for the broad range of applications

• A software architecture must facilitate this broad problem

• Generalization:

• This problem is a subset of a broader class of computing problems

• Acknowledge this perspective and design for change!

• Intelligent Signal Processing and Analysis

• Scope:

• Design for the broader problem

• Implement for condition monitoring of mobile underground mining equipment

3

Outline

• Introduction

• Reach of Intelligent Signal Processing and Analysis Applications

• Condition Monitoring of Variable-State Machinery

• Software Design Considerations

• Vision

• Use Cases

• Functionality

• Software/Hardware Implementation

• Proposed Architecture

• Enterprise Level Architectures for CBM in Mines (IREDES)

• Conclusion4

Introduction

• Primary research focus:• Monitoring Mobile underground mining equipment

• Algorithms and analysis to advance the state of the art for variable speed/load machinery towards this problem• Experimental laboratory test bench:

• Gearbox subject to dynamic load/speed

• Predictive maintenance strategies for this environment:• Fault detection

• Fault identification/diagnosis

• Prognosis

• Sensor failure analysis

• Integration into enterprise computing systems

• The problem can be generalized further • Intelligent Signal Processing and Analysis

5

Reach of Intelligent Signal Processing and Analysis

6

Condition Monitoring of Variable-State Machinery • A first step towards monitoring

mobile underground equipment

• Gearbox components subject to variable load and speed

• A challenging problem

• Non-linear mechanical response

• Complex vibration spectra

• Limited data availability

• Able to characterize normal “healthy” state with ease

• Faulted data too difficult/expensive

• Novelty Detection

• Tax’s SVDD preferred 7

CBM Variable-State Machinery • Research focused on gearboxes

• 50 Hp “speed” motor/VFD

• 25 Hp “load” motor/VFD

• Bearing and gear faults

8

CBM Variable-State Machinery Failing to consider speed or load

9

Multi-modal novelty detection

• Speed considered (fail to consider load)

• Technique: novelty detection (SVDD)

• Features: auto-regressive (AR) model for features

• Technique: “multi-modal novelty detection” with SVDD

• Features: Average speed and AR model

CBM Variable-State Machinery

10

System Identification

• Technique: normal novelty detection (SVDD)

• Features: system identification parameters

• (input shaft speed and load as inputs to system model and vibration as output)

• Advantage:

• Feature vectors from transfer function insensitive to time-varying parameters

• No double curse of dimensionality

• Generalizes well across untrained speed/load

• Disadvantage:

• Computationally inefficient

• Measure load and speed

Cross-Correlation

• Technique: normal novelty detection (SVDD)

• Features: parameters of cross-correlation signal from accelerometers on disparate locations of machine

• Advantage:

• Feature vectors insensitive to time-varying parameters

• Efficient

• No speed/load sensors required

• No double curse of dimensionality

• Generalizes well across untrained speed/load

• Disadvantage:

• ?

CBM Variable-State Machinery

11

System Identification Cross-Correlation

Software Design: Vision

• Intelligent signal processing• Takes multitude of real-world signals

• Processes

• Segments

• Extracts relevant information

• Classifies

• Dynamic routing of signals through each stage • At run time

• As configured by expert at setup

• Pattern recognition problem (next slide)

12

13

Software Design: Use Cases

• Range of solutions• A reflection of the market for various cost-benefit analyses

• Design suitable for broad range• Dedicated in-situ online monitoring

• Periodic monitoring• One monitoring computer transported from application to

application

• Environments• Underground

• Caustic

• Bandwidth limited

• Limited network connectivity

• Remote monitoring • Pipeline compressor stations?

14

Software Design: Functionality

• Software interface

• Remote networked

• Complete configuration of all algorithms and their interconnections

• Wide range of algorithms

• Signal processing

• Decision• Pattern recognition

• Novelty Detection

• Classification

• Expert systems

• Post-processing options

• Sensor failure analysis

• Prognostics

• Diagnostics

• Alarm reporting, storage, integration with other systems15

Software Design: Hardware/Software• Generic software designs preferred with no minimal

implementation language bias

• Idealized but unrealistic

• Object-oriented programming (OOP)

• Initial prototype developed in MatLAB OOP

• Final implementation in National Instruments’ (NI) LabVIEW

• NI hardware ideal for mobile underground mining environment

• Architecture demonstrated to be effective in MatLAB OOP

• Research results generated with this system

16

Proposed Architecture

• Extensible Intelligent Signal Processing

• At run time not just design time!

• Software design patterns advanced

• Design for broader problem but implement for CBM

• Challenge #1: Data comes from a variety of locations (e.g. networked sensors, historians, live sensors, disk)

• Solution: Define a DataSource module that will be common for all types of sources

• Handlers don’t need to know the actual source just how to ask for data

• Challenge #2: Need to dynamically route signals from DataSources

• Solution: Define a “Multiple User Samples Queue” to allow handlers to register for data and to retrieve that data at later times with a registration token received at registration time 17

Proposed Architecture

• Challenge #3: Handle different signal processing techniques in a common way

• Solution: Define a SignalConditionStrategy to allow the handler to pass signals through any of a variety of different strategies but with a common interface

• Different types of algorithms for feature vector generation is a type of this problem

• Filtering a noisy signal is a different example

• Generating features is a kind of signal conditioning

• Challenge #4: Handle different signal segmentation techniques in a common way

• Solution: Define a SegmentationStrategy module to define a common way of handling signals segmented with varying techniques

• Monitoring variable speed machinery: expert prefers segments based on constant number of shaft rotations rather than samples

18

Proposed Architecture

• Challenge #5: Dynamic run-time signal routing

• The user should be capable of selecting which data sources get routed through any of a variety of signal conditioning strategies that are in turn segmented and fed through analysis techniques

• Solution: create a SignalConditioner module that creates a hierarchy of DataSources and SignalConditioningStrategies

• Challenge #6: Support a variety of algorithms for decision-making purposes

• Pattern recognition, experts systems, etc.

• Solution: define a IntelligentAnalyzerStrategy module that allows the handler to route signals (i.e. feature vectors) through a number of user-selectable algorithms

19

Enterprise Level Architectures for CBM in Mines• Proposed architecture handles low-level processing of data for

intelligent signal processing and analysis

• Many applications of this broad class of problem could add significant value through integration at the enterprise level

• Particularly true for condition monitoring in mines

• Integration at the enterprise level could augment

• Operations planning

• Maintenance decisions

• Spare parts inventories

• This process is too often done in silos!

• A common standard for integration required

• International Rock Excavation Data Exchange Standard (IREDES) 20

IREDES

• XML-based communication schema

• Designed to make data exchanges generated by common classes of mining machinery the same

• Enables transmission of real-time data

• Portion of standard for CBM undefined at present

• Consider Open Systems Architecture for Condition-Based Maintenance

• Fulfillment of ISO 13374

• Lead by Boeing, US Navy, Rockwell Automation, Caterpillar

• Extensive UML model of high-level integration considerations

• Ideal for IREDES?

21

Conclusion

• CBM for mobile underground mining equipment a challenge

• Automated fault detection of variable speed/load machinery a first step

• Sound techniques developed that minimize classification error and should lead to early detection times

• Extension to true mobile underground equipment

• Consider diagnosis and prognosis

• Low-level data processing achieved with robust software architecture

• Implemented for CBM but designed for broader analysis problem

• Integration of low-level system achievable with OSA-CBM

• Mining can exploit these benefits via IREDES augmentation22