Condition monitoring of variable state machinery; gearbox to varying load and speed; objected oriented design; labview; matlab

1. Software Architecture for
Condition Monitoring of
Mobile Underground
Mining Machinery
Presented by: Dr. Markus Timusk, P.Eng.
Paper by: Jordan McBain, P.Eng. and Dr. Markus Timusk, P.Eng.
1

2. 2

3. 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 3
equipment

4. 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)
4
• Conclusion

5. 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 5
• Intelligent Signal Processing and Analysis

6. Reach of Intelligent Signal
Processing and Analysis
6

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

8. CBM Variable-
State Machinery
• Research focused on gearboxes
• 50 Hp “speed” motor/VFD
• 25 Hp “load” motor/VFD
• Bearing and gear faults
8

9. CBM Variable-State Machinery
Failing to consider speed or load Multi-modal novelty detection
• Speed considered (fail to consider load)
• Technique: novelty detection (SVDD) • Technique: “multi-modal novelty 9
• Features: auto-regressive (AR) detection” with SVDD
model for features • Features: Average speed and AR
model

10. CBM Variable-State Machinery
System Identification Cross-Correlation
• Technique: normal novelty • Technique: normal novelty
detection (SVDD) detection (SVDD)
• Features: system identification • Features: parameters of cross-
parameters correlation signal from
• (input shaft speed and load as accelerometers on disparate
inputs to system model and locations of machine
vibration as output) • Advantage:
• Advantage: • Feature vectors insensitive to
• Feature vectors from transfer time-varying parameters
function insensitive to time- • Efficient
varying parameters • No speed/load sensors required
• No double curse of dimensionality • No double curse of dimensionality
• Generalizes well across untrained • Generalizes well across untrained
speed/load speed/load 10
• Disadvantage: • Disadvantage:
• Computationally inefficient • ?
• Measure load and speed

11. CBM Variable-State Machinery
System Identification Cross-Correlation
11

12. 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. 13

14. 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
14
• Pipeline compressor stations?

15. 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 15
• Alarm reporting, storage, integration with other systems

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

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

18. 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 18
constant number of shaft rotations rather than samples

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

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

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

22. 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 augmentation
22