Transcript Document
Standardizing Access to Information from Onboard Mobile Mining Equipment Mark Bartlett Presented at: CIM Annual Meeting May, 2013 Mining Standards and Guidelines Group Technology & Connectivity Working Group Prepared by: 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… The Burning Platform: • 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: • 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… • The APIs can be simple or complex depending on the application (e.g. simple data stream or full bi-dir comms)… • Virtually all onboard systems have some external mechanism that allows an external connection (whether that is e-net, CAN, RS232, Bluetooth, USB, etc.)… The Burning Platform: New App • So….if someone else wants to connect, how can that be done?… 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 A Proposed Solution: New App • 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… The Proof of Concept: • Let’s 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) The Proof of Concept: • To simplify things, we will look at a typical incab display • Although these types typically incorporate the display process, it does not matter for the Proof of Concept 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 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) The Proof of Concept – Proposed Implementation: Mobile Server VIMS display info MMS display info VIMS data (simulated VIMS API) • 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 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 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 application’s features 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