Download presentation
Presentation is loading. Please wait.
Published byKeven Vore Modified over 10 years ago
1
Standardizing Access to Information from Onboard Mobile Mining Equipment Mark Bartlett Presented at: CIM Annual Meeting May, 2013 Mining Standards and Guidelines Group Prepared by: Technology & Connectivity Working Group
2
The Burning Platform: Currently, most mines have equipment…. Many with intelligent onboard systems…. They typically have some method to communicate… Using a variety of methods and protocols…
3
Each Process communicates to a specific application… Typically supplied by the applications vendor… The media can be a multitude of connections, but that is not important… What is important is that the applications can be located anywhere… The Burning Platform:
4
Regardless of the connection media, the external (not necessarily offboard) applications talk to their respective counterpart via a specific API created by the respective vendor… Virtually all onboard systems have some external mechanism that allows an external connection (whether that is e-net, CAN, RS232, Bluetooth, USB, etc.)… The APIs can be simple or complex depending on the application (e.g. simple data stream or full bi-dir comms)… The Burning Platform:
5
So….if someone else wants to connect, how can that be done?… New App The Burning Platform:
6
Considerations: Specifying the specific connection will probably not be accepted by the suppliers – Products are already widely distributed – Manufacturers are reluctant to standardize on a specific connector and/or media They have other internal requirements that most likely prevent a design change of that magnitude – such changes take years! Specifying specific protocols have the same issues as above Publishing existing APIs creates vendor concerns with allowing access to proprietary data and/or machine control
7
Request the suppliers to supply a published API to allow customers/third parties access to non-proprietary data and information… The current (proprietary) APIs can coexist… New App A Proposed Solution:
8
The Proof of Concept: Lets consider an in-cab display – This can be any kind of display Regardless of the type, there is typically a process that controls the display – The process can be internal or external to the display – The process controls what is displayed and when (along with any feedback (operator input)
9
The Proof of Concept: To simplify things, we will look at a typical in- cab display Although these types typically incorporate the display process, it does not matter for the Proof of Concept
10
The Proof of Concept: The API will specify: – A standardized scheme to allow operator access to any of the applications – A priority scheme to allow events out of the ordinary to display relevant information The API provides the interface for each application to present information to the operator What we will need is an API
11
The Proof of Concept: The Situation Awareness Working Group will need to define the various display schemes – Standard operator access (e.g. utilities) schemes – Priorities/Alerts What happens screen-wise? How are acknowledgements done (what happens to the display)? What is on a home screen? What operator input is allowed and when? Etc…. A third party (like GuardVant) could implement a display server (i.e. display process) using the display API schema set by the SA working group. Another third party (like MMS) could incorporate the API and send routine information to the display server, and receive input from the operator. The display server should have the capabilities of interfacing to at least one other pre-existing system (e.g. VIMS)
12
The Proof of Concept – Proposed Implementation: For purposes to prove the concept: – The Mobile Server would control the display The Display Process and Display API would be implemented in the Mobile Server The Mobile Server would directly connect to VIMS and simulate a (unidirectional) VIMS API Display feedback (touch sensitive input) will go back to the MMS process via the API VIMS data (simulated VIMS API) VIMS display info MMS display info Mobile Server
13
The Proof of Concept – Proposed Implementation: We could then demonstrate: – The ability for an operator to select a display A standard dashboard Various vital signs display screens Various MMS standard displays (with operator input) – Various Alarm screens Including Operator acknowledge/clearance
14
Commercial Considerations: Like radios, displays are commodities: – Implementing APIs provides the flexibility to evolve and adapt to future generations of display technologies Cell Phones and Tablets already provide enhanced APIs Screen control can be handled by the display process features In-cab display manufacturers can compete on features Applications developers can focus and compete on the applications features
15
Final Thoughts: APIs allow for flexible access to information APIs do not dictate interface considerations to the suppliers/developers allowing innovation APIs allow protection for proprietary data and equipment control APIs promote a competitive environment where developers can focus on enhanced application features rather than be limited by data access APIs allow established platform suppliers to retain market share
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.