the anatomy of autonomy

Autonomous Value Driven Program | i

The Anatomy of Autonomy

Your guide to achieving a mature, value-driven autonomous program

By Andrew Crose, VP - Autonomous

Autonomous Value Driven Program | ii

Many mining houses, OEMs, and start-ups are working on different levels of autonomous programs. At a high-level, this is exciting

but at the detail level, it can be daunting. Assessing the functional maturity of a complex system takes a careful eye. The weakest link

analogy holds especially true in the chain of technology, service and support required to deploy an autonomous ecosystem.

Let’s break down the pieces with definitions to understand the components and subcomponents.

“

Autonomous Value Driven Program | 3

| Autonomous Ecosystems

An autonomous ecosystem comprises many technology areas, each with its own technology stack.

This technology stack has the large breadth and depth required to achieve an autonomous program.

Autonomous Ecosystem

Commandand Control

World Perception and Awareness

Physical ControlSystems

SafetySystems

SupportingTechnology

SupportingServices


• Management of equipment assignments

• Contention management of equipment to equipment/objects

• Situational logic on intersections

• Choreography of vehicles to other vehicles (ie, shovels to trucks)

• Task assignments

• Shift scheduling

• Alignment to strategic goals

• Short interval control of plans to actuals

• Tracking and reporting on results

Within the Command and Control technology stack reside many common technologies:


Within this technology stack are varying maturity levels for the technologies. For example, management of equipment assignments is typically filled by the fleet management layer. Does the fleet management layer include a dynamic assignments optimization algorithm, or just a locked truck and shovel logic? Can it account for ore grades and dynamic blending targets, or is this just set at the shift schedule layer and reconciled later? This decision alone can make the difference between an autonomous program that increases or decreases a mine’s productivity.

Another example is the safety layer. This area can be of greatest concern. Speaking with many autonomous project leaders, it appears the safety layer has often been neglected or is an early stage safety technology.

Many autonomous programs today are still in a generation 1-3 safety layer program. For example, an autonomous program may use a Gen 3 sensor set for layers of awareness but still lack true voice-to-voice (V2V) communication on a Gen 1 mobile-to-server to mobile vehicle-to-vehicle layer. This should be considered a serious concern across the industry. Similar generational approaches exist for each of these areas and hold true with the analogy, the weakest link in the chain can break the program.

| Technology maturity stack

Safety GenerationsHere’s one way to consider the safety generations:

Generation 1early 2000s• Mobile to server to mobile awareness• Vehicle to vehicle only• High latency• Single sensor (GPS)

Generation 22006 - 2010• Vehicle to network to vehicle• Vehicle to vehicle only• Medium latency• Single sensor (GPS)

Generation 32010 - 2015• Vehicle to vehicle object• Layers of awareness (GPS, radar, LiDAR, Camera)• Low latency

Generation 42015 - present• Vehicle to vehicle, object, person• Mulitple layers of sensor fusion (GNSS, radar, camera, ultra wide band, etc.) • Low latency• Situational reporting

Generation 5(next generation)• V2X capabilities• Objection detection and identification• 4D situational awareness• Open integration with ecosystem (FMS, slope monitoring)


One Stop Shop vs. Best of Breed vs. Open Architecture

1 Early AutonomousOne Stop Shop – With early generational autonomous programs, the technology stacks were not readily available. To enable a site, programs largely had to build the capability in-house, creating an artificial one-stop shop with only one vendor able to provide a complete solution. The downside, in some instances, is proprietary systems were created which discouraged later best-of-breed components from replacing older generational components of the technology stack, stifling innovation.

3 Future is NowBest of All – As we drive into future autonomous, a best-of-all approach will appear. Companies like Hexagon will introduce best-of-breed technologies to the market while adding capabilities to deploy a one-stop shop and actively encouraging an open architecture approach. This is a natural evolution as many autonomous programs will just want to implement from a one-stop shop; others will want to upgrade components of their autonomous program with best-of-breed point solutions. By enabling both, via open architecture approaches, customers can derive the value in the approach that fits their unique situational needs.

2 Mid-AutonomousPartial Open Architecture – This is where many in the market are today. New entrants entering the market lack the ability to develop the full stack as quickly as the market requires. This requires partnership and open architecture approaches to bring additional and new technology components into the autonomous market.


Deployment, Service, and SupportMuch like the technology itself, the deployment, service, and supportability of autonomous technology face maturity curves of their own. Early projects were very much custom-developed. Enabling the first autonomous haul truck, more than 20 years ago, was a significant challenge, not just for technology but for people to deploy it. Roles were not defined; support models were not understood, and training materials were not developed.

Project ServicesAs the maturity curve developed, the roles, responsibilities, and requirements followed more like traditional technologies. As autonomous deployments have matured, the roles have become more defined. Project phase and program phase have clearer hand-offs, scopes of work are more clearly defined, ensuring these projects avoid becoming never-ending deployments.

Project Configurations

Early ProjectsThese projects were more like custom software development than product deployments. Early autonomous projects took a decade to conclude as scope was not understood upfront, change requests were frequent, and technology evolved in-real time with the project deployment.

New Development ProjectsThis is where most of the market is today. Projects are still mostly development projects rather than deployment projects. New technology or new integration partnerships are seen with each deployment. Project scopes are clearer in deliverables, but commonly with unknowns or untested items to be tackled for the first time during the project.

Off-the-shelf ProjectsAutonomous projects can now be considered in many regards as product- deployment projects. Well-defined scopes with configurations, as opposed to custom work, are established and managed to successful deployment.


| Trade OffThe trade-off between “new development” and “off-the-shelf” does not mean that new development projects should be avoided. This should be an active discussion on the goals of both the site and the supplier to determine if this project is to deploy an off-the-shelf standard, or to push the boundaries to reach a new best-of-breed solution within a portion of the ecosystem. The key is to understand the trade-offs of those decisions and the changes to the project plan and project management with each. An off-the-shelf project would have clearer scopes, timelines, and budgets where a new development project can push the boundaries of the technology to enable creation of new value for the site and overall industry.

New development projects

• New innovation

• New value

• Less defined scope

• Longer timeframes

• Larger budget

• Risks “orphan” technology

Off-the-shelfprojects

• Innovate “as-is”

• Configuration of existing product

• Clearer scope

• Shorter timeframes

• Smaller budget


| Orphan TechnologyThe creation of orphan technology is one of the biggest risks with new development projects. Orphan technology is created when the custom development created during the project is not adopted into a later off-the-shelf product. This creates a situation where the maintenance and ongoing project support are as cumbersome and expensive as the project itself. This is a critical reason why new project deployments should create new innovation that is returned to the products from the supplier, reducing later maintenance costs by enabling a standard product for support across an industry of users, as opposed to a custom project that requires ongoing support only for one user or site. As such, orphan technology typically has a significantly shorter lifecycle than development that becomes a feature of an off-the-shelf product later.


Types of Projects

Post-Project SupportPost-project support is the beginning, not the end of the journey. Autonomous projects should not be technology for technology’s sake, but rather with real business intent which is only realized in value in use. Unfortunately, many projects fail in this crucial phase of an autonomous journey.

Zombie ProjectsThese never-ending projects epitomize early autonomous. Created by poorly aligned scope, over-estimation of project capability, and/or lack of buy-in from operations to transition from project to program, many early and some current autonomous projects become stuck in this never-ending loop.

Abandoned OrphansLikewise, many autonomous projects began as custom development. In many cases this custom development was performed by suppliers without a plan to turn the development into off-the-shelf product, or the customization was too custom to be utilized by other customers, or intellectual property ownership disputes between supplier and autonomous site led to products that were difficult to productize. The industry experiences many of these projects, which eventually become unsupportable.

Proprietary StalematesThis type of autonomous project becomes stuck if developing standards and open architecture systems aren’t embraced. By missing out on standards, ISO for example, these projects eventually stall as new development - whether from the original supplier or new suppliers – unable to integrate and deliver new value in use.

Abandoned PropertyMany autonomous projects face this reality. Without a belief from the beginning that the project will transition to a program, these projects lack operational buy-in to maintain the system. Tell-tale signs of an abandoned property project include a lack of a maintenance and support agreement with the supplier, no software and hardware lifecycle plans, and a lack of an easily identifiable program owner.


Project Management (PM)“I keep the project on time, in scope and on budget,following PMP® principles or similar methodology. I organize our service and support team along with sub-contractors to deliver the project.”

Subject Matter Expert Principle Engineer (SME PE)“I apply system configuration and architecture, accounting for the mine’s unique characteristics. I am hands-on when it comes to configuration, training and autonomous deployments.”

Software Project Engineers (SW PE)“Across onboard and central server computers, I am responsible for system deployment from a software perspective.”

Hardware Technician (HW Tech)“I physically install the system, ensuring readiness for initial sign-off and ease of maintenance later.”

Trainers“We are responsible for training on software, maintenance and hardware, ensuring the comprehensive knowledge-transfer required to use the system.”

Change Management“We help mine staff to develop and deliver changemanagement so they can introduce the new world of autonomy.”

Supplier Executive Sponsor“Given the size and implications of a large, complex deployment, I am on hand to provide executive leadership, decision-making and action when it’s needed.”

Project Management (PM)“I organize the mine’s resources to deliver the project, aligning operations, information technology, operational technology, maintenance, and site management to the project goals of delivering on-time, on-budget, and within scope.”

Program Management“From the beginning, I help stakeholders understand who will own and run the autonomous program after the project concludes. Sometimes my role falls under the description Operational Technology.”

Information Technology (IT)“I ensure timely access to IT infrastructure within the confines of IT policies to enable the technology necessary for an autonomous ecosystem.”

Operations“We are the customer for an autonomous project, actively involved throughout so scope and deliverables are aligned to our objectives and channelled for ongoing success.”

Maintenance“Our role is critical for the reliability of autonomous and non-autonomous equipment.”

Change Management“Pivotal to an autonomous program is the role of change management, which ensures organizational alignment of staff at all levels to buy into the transition from a manual to an autonomous operation.”

Site Executive Sponsor“Given the size and implications of a large, complex deployment, I am on hand to provide executive leadership, decision-making and action when it’s needed.”

Supplier SideThese project-focused roles are supported behind the scenes by tiers of support from product management, development, information security, etc. to ensure best practices and quick resolutions to issues experienced during the project.

Autonomous Site StaffBeyond the site and the supplier are enabling roles, comprising the local community, OEM equipment providers, outsourced third parties in IT, equipment maintenance, and others.


Concluding thoughts

Autonomy is still very much an evolving space. Early systems from OEMs are hitting critical walls that will only be passed with an open autonomy approach to enable best-of-breed

opportunities to create new capability. Coordinating multiple vendors, multiple contracts, and multiple integration points creates its own challenges. This means an even more

powerful drive for best of breed, open architecture, and one-stop shop for the best solution.

Autonomous projects are also evolving. No longer are they custom development for the first time. They range from off-the-shelf deployments to new development projects.

Understanding which portions of your autonomous project are off the shelf and which are new development is critical to how you manage your projects successfully.

Lastly, the goal is not to deliver a successful autonomous project. The goal is to deliver value in use over time via an autonomous program. Aligning your organization, your

supplier, and your ongoing commercial relationships along this goal is critical to long-term, value-in-use, delivered to your organization.


Definitions:Autonomous Ecosystem: A series of interconnected technologies enabling an autonomous operation; for example, an autonomous load and haul ecosystem comprises autonomous, semi-autonomous, and manned haul trucks, loading units, auxiliary equipment, light vehicles, people, haulage network, loading and dumping areas, etc.

Command and Control: A set of organizational and technical attributes and processes that employs human, physical, and information resources to solve problems and accomplish missions.

World Perception and Awareness: The layers of technologies that facilitate the onboard and remote situational awareness used by the physical control systems and command and control processes to enable autonomy; examples include onboard object detection and classification and 4D live terrain model.

Physical Control Systems: The systems that physically control the vehicles; examples include drive-by-wire technology and robotic stacks for physical machine control.

Safety System: The identification, analysis, and application of controls using a systems-based approach for remediation of unsafe actions; Examples include the use of object detection technologies to identify unsafe driving actions that trigger a change in driving path or braking action.

Enabling Technologies: Technologies that enable the ecosystem; examples include communication layers, servers and infrastructure, information security, and functional safety

Enabling Services: Services that enable the ecosystem; Examples include project managers, project engineers, system engineers, maintenance and technicians, change management, and others.

Open Architecture: a type of computer architecture or software architecture intended to make adding, upgrading, and swapping components easy.

Best of Breed: any item or product considered to be the best of its kind.

Off-the-shelf: products are packaged solutions which are then adapted to satisfy the needs of the purchasing organization, rather than the commissioning of custom-made, or bespoke, solutions.


About HexagonHexagon is a global leader in sensor, software and autonomous solutions. We are putting data to work to boost efficiency, productivity, and quality across industrial, manufacturing, infrastructure, safety, and mobility applications.

Our technologies are shaping urban and production ecosystems to become increasingly connected and autonomous — ensuring a scalable, sustainable future.

Hexagon’s Mining division solves surface and underground mine challenges with proven technologies for planning, operations and safety.

Hexagon (Nasdaq Stockholm: HEXA B) has approximately 20,000 employees in 50 countries and net sales of approximately 4.4 bn USD. Learn more at hexagon.com and follow us @HexagonAB.

Visit us at hexagonmining.com

the anatomy of autonomy

Documents