Software Architecture For Condition Monitoring Of Mobile Underground
Download as PPTX, PDF1 like725 views
The document discusses a software architecture designed for condition monitoring of mobile underground mining machinery, focusing on intelligent signal processing to address the diverse challenges of automated monitoring. It highlights the need for flexible algorithms and integration into enterprise computing systems to enhance predictive maintenance strategies. The proposed architecture aims to facilitate data handling and algorithm processing, ensuring real-time data exchange and minimizing classification errors for effective monitoring of variable-state machinery.
Software Architecture For Condition Monitoring Of Mobile Underground
- 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