software architecture for condition monitoring of mobile underground
DESCRIPTION
Condition monitoring of variable state machinery; gearbox to varying load and speed; objected oriented design; labview; matlabTRANSCRIPT
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