Standardizing Access to Information from Onboard Mobile Mining Equipment Mark Bartlett Presented at:...

Standardizing Access to Information from Onboard Mobile Mining Equipment

Mark BartlettPresented at:

CIM Annual Meeting

May, 2013

Mining Standards and Guidelines Group

Prepared by:

Technology & Connectivity Working Group

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…

• 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…


• 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)…


• So….if someone else wants to connect, how can that be done?…

New App


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

• 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:

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)


• 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


• 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 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:

• 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

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

Standardizing Access to Information from Onboard Mobile Mining Equipment Mark Bartlett Presented at:...

Documents

Transcript of Standardizing Access to Information from Onboard Mobile Mining Equipment Mark Bartlett Presented at:...