AHS

Product Support Training Program

Student Guide: ONSITE SUPPORT COURSE

Page 1
 AHS

Page 2
 AHS

Contents

Legal Notice 7
Trademarks 7

Overview 9
Program Overview 9
Course Overview 10

Module 1: Ticket Stages 13

Support Levels 15
Level 1 15
Level 2 16
Important Ticket Fields 17
Requester 17
Organization 17
Request Type 17
Severity Level 18
Ticket Priority 18
Category 18
Product & Version 19
Site 19
Initial Ticket Stages 20
New 20
Waiting for Assignment 21
Assigned 21
Information Requests 22
Level 3 Information Request 22
Waiting for Customer Input 22
Released to Level 1 23
Waiting for Install 23
Technical Completion / Closed by Agent 23
Merging Tickets 24
Resources 25
Zendesk User Guidelines 25

Page 3
 AHS

Module 2: Field Equipment & Support 29

Field Equipment Connections 31
Field Computer 32
Specifications 32
Operating System 32
File Structure 33
Connection Techniques 34
Common Tasks 35
Radio 37
Operating System 37
Connection Techniques 37
Common Tasks 38
Field Equipment GNSS Receivers 39
Operating System 39
Connection Techniques 39
Common Tasks 41
Appendix: Additional Tunneling Scenarios 43
Tunnel through PTX-C 43
Tunnel Windows (with TRU) -> Linux -> PTX-C -> GPS 43
Automate Tunnel with a Hop [Helpful for Layer 3 Systems] 43

Module 3: Troubleshooting & Investigation 47

Lesson 1: Troubleshooting 49
Symptoms 49
Procedures 49
Severity 52
Lesson 2: Investigation 54
Playbacks 54
Log Gathering 55
Timeline 63

Page 4
 AHS

Module 4: Installation & Configuration 67

Important Notes 69
Physical Installation 69
Site-Specific 69
Documentation 69
Equipment Configuration 71
Physical Measurements 71
Profile Recommendations 72
Review & Approval 72
DISPATCH 73
FrontRunner 74
Field Equipment Hardware Installation & Configuration 75
GNSS Receiver Configuration 76
Radio Configuration 76
Field Computer Configuration 76
Master Checklist 77
Support Tasks 78
Other Field Equipment 78

Module 5: Simulator Installation & Support 81

Important Notes 83
Site-Specific 83
Documentation 83
Simulator Uses 84
Training 84
Testing 84
Development 84
Simulation Services 85
FrontRunner Simulation Services 85
DISPATCH Simulation Services 87
Simulation Scenarios 89
Support Tasks 91
Update Customer Simulation Databases 91
Add Equipment 92

Page 5
 AHS

Module 6: Hardware Validation & RMA 95

Definitions 97
Hardware Validation & Testing 99
AHS Hardware Family Page 99
Documenting Hardware Failure 100
Return Merchandise Authorization 102
General RMA Procedure 102
Spares 105
Part Numbers 105

Page 6
 AHS

Legal Notice

The content of this document is strictly confidential and contains proprietary information. The contents of these materials are
protected by federal and international intellectual property laws. No portion of these materials may be reprinted, republished,
modified, reproduced, sold, or distributed in any form without the express written consent of Komatsu Ltd. All copyrights and/or
trademarks contained in these materials are the sole and exclusive property of their respective owners.
These materials, including third party information, are provided for information purposes only. Actual specifications may vary from
those documented in these materials.
Copyright © 2022 Komatsu Ltd. All rights reserved.

Trademarks

"FrontRunner" and the FrontRunner logo are trademarks of Komatsu Ltd., registered in the U.S. and other countries.

All other brand names and product names used in this document are trademarks, registered trademarks, or trade names of their
respective holders.

Page 7
Onsite Support: OVERVIEW
AHS

Page 8
Onsite Support: OVERVIEW
AHS

Overview
Before you begin this course, please note that as of October 2021, Tier 1.5 has been removed and Regional Support engineers are
now referred to as Tier 2. Subsequently, Tier 2 has become Tier 3, and Tier 3 has become Tier 4. To recap:
• Tier 1: Onsite Support
• Tier 2: Regional Support (previously Tier 1.5)
• Tier 3: Global Support (previously Tier 2)
• Tier 4: Product Development (previously Tier 3)

Also note that Levels will be used to describe the levels of support in Zendesk, but Tiers will remain as group titles elsewhere:
• Zendesk Level 1 support is provided by Tier 1: Onsite Support
• Zendesk Level 2 support is provided by Tier 2: Regional Support (previously Tier 1.5)
• Zendesk Level 3 support is provided by Tier 3: Global Support (previously Tier 2)
• Zendesk Level 4 support is provided by Tier 4: Product Development (previously Tier 3)

To avoid subsequent confusion with the Level 1, 2 and 3 course names, courses have been renamed. Previous course names are
shown in parentheses, for example, the Level 1 course has been renamed Foundations, and is referred to as Foundations (Level 1).

Program Overview

The Product Support Training Program consists of five levels of training which provide a matrix of courses to be undertaken by the
three roles within Product Support.

Roles

The three roles within Product Support are:

Tier 1: Onsite Support

• Distributor / Komatsu employees based at each customer site
• Provide direct onsite Regional Support
• Support the system at a high level
• Are technically astute
• Perform some basic software tasks in addition to hardware maintenance

Tier 2: Regional Support

• Komatsu employees based at the regional office
• Provide Regional Support to customers within the region
• Support the system at an advanced level
• Are more technically astute and have a deeper understanding of the application and support tools
• Responsible for on-site deployments and upgrades

Tier 3: Global Support

• Komatsu AHS Global Support employees based in Tucson
• Provide remote 24/7 advanced system Global Support
• Support the system at an advanced global level
• Are more technically astute and have a deeper understanding of the application and support tools
• Responsible for deployment and upgrades at customer sites

Page 9
Onsite Support: OVERVIEW
AHS

Courses

The program consists of five courses built around the five levels of knowledge/skills required of the three roles:

Foundations Onsite Support Regional Support Global Support Deployment Support

^ Role Course >
(Level 1) (Field Engineer) (Level 2) (Level 3) (Deployment)

Tier 1: Onsite Support Mandatory Mandatory Recommended n/a Recommended

Tier 2: Regional Support Mandatory Recommended Mandatory Recommended Mandatory

Tier 3: Global Support Mandatory n/a Mandatory Mandatory Mandatory

Course Overview

This course consists of six modules which will take up to eight weeks to complete. Most learning is self-paced. Your mentor will set a
final deadline for completion of all training. Employees are expected to manage their time accordingly to complete all online lessons,
assessments, and tasks.

Teaching & Learning

Modules consist of online lessons and tasks.

• Lessons are taken via online, self-paced learning.
• Lesson knowledge is assessed via an online self-paced Knowledge Assessment.
• All lessons include the demonstration of Tasks. Time is available between lessons for self-paced learning to practice these
tasks.
• Tasks are assessed via a Competency Assessment where your mentor will evaluate your ability to perform each task.
• This Student Guide accompanies the lessons and can be used for reference throughout self-paced learning.

MODULE LESSON SELF-PACED LEARNING

Program Overview 30-minute mentor meeting N/A

Online lesson & assessment

Module 1: Ticket Stages 90-minute online lesson
Tasks
Online lesson & assessment
Module 2: Field Equipment & Support 90-minute online lesson
Tasks
Lesson 1 Troubleshooting: 60-minute online lesson Online lessons & assessment
Module 3: Troubleshooting & Investigation
Lesson 2 Investigation: 90-minute online lesson Tasks
Online lesson & assessment
Module 4: Installation & Configuration 70-minute online module
Tasks
Online lesson & assessment
Module 5: Simulator Deployments, Upgrades & Support 90-minute online module
Tasks
Online lesson & assessment
Module 6: Hardware Validation, Testing & RMA Processes 60-minute online module
Tasks

Page 10
MODULE 1: Ticket Stages

MODULE 1: Ticket Stages

Page 11
MODULE 1: Ticket Stages

Page 12
MODULE 1: Ticket Stages

Module 1: Ticket Stages

Tickets are created by Tier 1 engineers. This module will describe the Level 1 ticket stages.
The module will also describe the escalation of tickets to Level 2 (Tier 2: Regional Support) engineers, Level 3 (Tier 3: Global Support)
engineers, and Level 4 (Tier 4: Product Development) engineers, and how you can effectively assist Global Support to solve tickets.

Learning Objectives

At the end if this module, you will be able to:

• Explain the important ticket fields.
• Explain the Level 1 stages of a ticket.
• Explain the Level 1 stages of a ticket that has been escalated to Level 3.
• Explain the stages of a ticket that has been released back to Level 1.
• Demonstrate knowledge of the resources created to assist you in your role.

Assessment

• Complete the online lesson.

• Complete the online assessment.
• Complete the tasks at the end of the module.

Page 13
MODULE 1: Ticket Stages

Page 14
MODULE 1: Ticket Stages

Support Levels
Each support Tier plays an important role in the Zendesk ticketing process. Module 2: Product Support, of the Foundations (Level 1)
course included a general overview of the ticket stages process for all Tiers. Note that the Ticket Stages diagram has been updated:
Levels are used to describe the Product Support stages in Zendesk. However, Tiers will remain as group titles elsewhere.
Tickets are created by Tier 1; therefore Tier 1 engineers need to have a thorough understanding of the Level 1 stages and the
information required to move a ticket through these stages. If a ticket cannot be solved by Tier 1, it is escalated to Level 2. The
information provided by Tier 1 is vital to assist Tier 2: Regional Support, Tier 3: Global Support, and Tier 4: Product Development
engineers, to effectively solve tickets.

In this module we will describe the stages that Tier 1: Onsite Support, and Tier 2: Regional Support use the most: Level 1 and Level 2.

Level 1 Ticket Stages

Figure 1: Level 1 Ticket Stages Workflow Diagram

Page 15
MODULE 1: Ticket Stages

Level 2 Ticket Stages

Figure 2: Level 2 Ticket Stages Workflow Diagram

Page 16
MODULE 1: Ticket Stages

Important Ticket Fields

When creating a ticket, the fields on the left-hand side are vitally important. They help to
associate the ticket to its customer, customer site and region. They enable sorting, filtering,
and searching via fields, for example, request type, product, and tags. They also provide key
reporting information that ties in with the Service Level Agreement (SLA) and our ISO 9001
standard for quality.
Ticket fields were described in detail in Module 2: Product Support, of the Foundations (Level
1) course, the most important ticket fields that Tier 1: Onsite Support, and Tier 2: Regional
Support engineers must complete will be described here.

Requester

When creating a new ticket, the first field to be completed is Requester: Type your name in the
Requester field to search. When you select your name, the Organization field may appear if
your Zendesk Agent account is attached to an organization.

Organization

In most cases the Organization field is used to specify which customer site created the ticket.
However, the Organization field may not be present for your Zendesk agent account, (check
with your supervisor if you are unsure if your region uses the Organization field). Scenarios
including unexpected behavior, issue, feature request, operational question, or an
infrastructure support question (network / virtualization support) would all have their
organizations set to their customer site. When the customer site is specified in this field and
the Category is set to Customer Care Agreement, the SLA is initiated.
The Organization field will be set to Modular if the ticket was created for an internal request.
Modular should be used when a question, concern or other request stemmed from an internal
Komatsu Mine Technology Solutions (MTS) team member or distributor. The customer should
have no visibility or expectations of these requests as they are not tracked under their SLA, and
therefore no SLA is applied.

Request Type
Figure 3: Ticket Fields
The Request Type field, once completed, enables the quick sorting and filtering of reports.
There are multiple Request Types to select from:
• AHS RMA Request • Performance Assurance
• Configuration Changes • Preventative Maintenance
• Create Zendesk Account • Question
• Encryption • RMA Request
• Improvement • System Audit
• Issue • System Install or Upgrade
• Other • GNSS Testing & Monitoring
Request Types are self-explanatory, however, if you are unsure which one to use when first
working on a ticket, ask your Ticket Master for advice.

Figure 4: Organization Ticket Field

Page 17
MODULE 1: Ticket Stages

Severity Level

The Severity Level field should always be filled out when the ticket is first created. This field, along with the Organization field, are
the most important fields used to track customer SLA deadlines.
As described in Module 2: Product Support, of the Foundations (Level 1) course, the severity level determines the time to resolve a
ticket, as shown in the tables below:
Service Level Agreement (SLA) Table

Escalation Times for Containment Escalation Times for Countermeasure

SLA Contract Zendesk SLA Target SLA Target
Severity Level Severity Level Containment Time Countermeasure Time
Tier 1 Tier 2 Tier 3 Tier 4 Tier 1 Tier 2 Tier 3 Tier 4

Critical Emergency 1d 30mins 2hr 3hr - 4d 2hr 8hr 1d 2d 12hr

Severe Severe Impact 2d 1hr 2hr 6hr - 10d 5hr 10hr 2d 7d 9hr

Limited Limited Functionality 10d 5hr 1d 3d - 4w 14hr 3d 8d 16d 8hr

Non-Critical
Minor Error 15d 1d 2d 5d - 6w 3d 6d 14d 19d
Not Applicable

Suncor Specific Service Level Agreement (SLA) Table

Escalation Times for Containment Escalation Times for Countermeasure

SLA Contract Zendesk SLA Target SLA Target
Severity Level Severity Level Containment Time Countermeasure Time
Tier 1 Tier 2 Tier 3 Tier 4 Tier 1 Tier 2 Tier 3 Tier 4

Critical Emergency 4h 30mins 2hr 3hr - 4d 2hr 8hr 1d 2d 12hr

Severe Severe Impact 1d 1hr 2hr 6hr - 10d 5hr 10hr 2d 7d 9hr

Limited Limited Functionality 10d 5hr 1d 3d - 4w 14hr 3d 8d 16d 8hr

Non-Critical
Minor Error 15d 1d 2d 5d - 6w 3d 6d 14d 19d
Not Applicable

Ticket Priority

Ticket Priority is used to highlight the urgency of the issue. Although it will not modify the SLA deadlines, consider utilizing this field
to prioritize your daily tasks. When assigning the Ticket Priority, ensure that it is an accurate level that applies to the severity of the
situation and request.

Category

The Category field is also used in SLA calculations. However, for the issue to be tracked under the customers SLA, the category must
be set to Customer Care Agreement. Further categories, as listed below, are used for the other services:
• Customer Care Agreement
• Fee for Service
• Fee for Service – Not Charged
• Fee for Service – Times and Materials
• New Generic Feature Request
• Other
• Project

Page 18
MODULE 1: Ticket Stages

Product & Version

The Product and Version fields are two separate fields that should always be considered when filling out a ticket. These fields
provide important reporting filters for tickets:
• Product consists of a list of all Modular Mining products: Determine which product the issue is related to and select
that product.
• Version consists of a list of versions of the product selected: Apply the current version of the product in use at that site.

Site

The Site field is required for all AHS tickets. This field is used as a key filter for many Zendesk reports:
• If you are creating a ticket for a specific customer and site, select the customer’s site name from the list.
• If you receive a support request from a customer who may not be associated with a particular site, then select the All
<customer> site option.

Page 19
MODULE 1: Ticket Stages

Initial Ticket Stages

When a ticket is created, the New stage is applied. The new ticket is then evaluated by the Ticket Master and assigned to a Tier 1
engineer for investigation.

New

The Tier 1 engineer who creates the ticket, will apply the New Ticket macro. The macro will provide the engineer with a brief
questionnaire to complete, to explain the basic details of the issue.
The questionnaire will ask: Macros are an automation tool that allows you
to set specific fields, variables and provide text
• What symptoms were experienced by the operator? templates for the engineers to follow.
• The time and date the issue occurred.
The macro will automatically:
• What actions, if any, were used to contain the issue?
• Which equipment / locations were involved? • Update the stage.
At this stage only the questionnaire requires completion. It is not • Update the assignee.
immediately necessary to build a detailed timeline or provide logs.
• Provide questions for the engineer to
When the questionnaire is complete, the stage is updated through the macro, complete in the comment box.
to Evaluation. The ticket is evaluated by the Tier 1 Ticket Master, who will
When you click Submit in Zendesk, the ticket is
then assign the ticket to a Tier 1 engineer.
submitted with the macro changes applied.

Macros

Further macro fields to be completed at the New stage are:

Date
Time
Description from Operators/Symptoms
Equipment Involved
Operational Context
Actions Taken by Operators
Actions Taken to Contain Problem

For New Return Merchandise Authorization (RMA) Tickets:

Date
Client/Site
Hardware Component
MMS Part Number
Serial Number
Equipment Removed From
Zendesk Troubleshooting Ticket and TSI (if possible)
Description of Hardware Problem
Troubleshooting Done
Testing Completed

Page 20
MODULE 1: Ticket Stages

Waiting for Assignment

When the ticket has been evaluated, the Ticket Master will typically move the ticket through to the Assigned stage. However, other
stages that could be used are:
• Waiting for Assignment is used when there is not an immediate resource available to begin their secondary analysis.
• Waiting for Customer Input is used when we need information from the customer.

Macros

Macros to be completed at the Waiting for Assignment stage are:

<No Notes Required>
Waiting for Customer Input
Operational Problem Statement
Status of Investigation
Operational Steps to Resolve Issue
Feedback from Customer Required
Corrective Actions

Assigned

Once in the Assigned stage, the ticket is ready for the first deep analysis by the assigned Tier 1 engineer, who will:
• Gather all applicable logs from the various sources in the field and in the central control infrastructure.
• Perform log analysis and generate timeline of events through log and playback review.
• Provide the operator context, a sequence of events and their experiences.
• Review the Zendesk database for similar instances and occurrences.
It is very important that all these steps are exhausted before even considering which stage the ticket is moved to next.
When the above analysis is complete, the ticket is reviewed by the Ticket Master who will then move it to the appropriate next
stage. Depending on the issue and analysis, potential next stages are:
• Waiting for Install / Installation means that the issue was fixed in a later version. We would therefore request that the
customer upgrades their version of FrontRunner or DISPATCH.
• Technical Completion means that the issue is solved, and the ticket is closed. Note that this stage is automated for the ticket
to close after 28 days.
• Escalated to Level 2 means that the issue has not been solved and requires the involvement of Tier 2: Regional Support.
• Escalated to Level 3 means that the issue has not been solved and requires the involvement of Tier 3: Global Support.

Macros

At the Assigned stage, macros are:

Initial Problem Statement
Severity
If more than one problem state below and create additional tickets and references
Sub-System Affected
Official Documentation Related
Reported in Other Zendesk Ticket
Required Data for Analysis

Note that the Waiting for Install and Technical Completion macros are listed in the Released to Level 1 macros section.

Page 21
MODULE 1: Ticket Stages

Information Requests
Even when a ticket cannot be solved, and it is escalated to Level 3, Tier 1 assistance may still be required. The Tier 3: Global Support
engineer could identify that additional information is required, such as further logs, operator context, or physical device information.
In this event, the ticket will be de-escalated back to Level 2, through a stage called Level 3 Information Request. In some cases, the
Tier 2: Regional Support engineer can provide the information requested. However, at other times the request will be sent to Level 1
for the Tier 1 engineer to complete.

Level 3 Information Request

When a ticket is de-escalated to Level 2 or Level 1, the Ticket Master will again review the ticket to assign the request to an engineer
for information gathering. The stage will remain as Level 3 Information Request throughout this process, and then be Escalated to
Level 3 once the information request is complete.
When providing information for a Level 3 Information Request, it is good practice to not only provide the logs requested, but also
some further log analysis. Also, if Tier 3: Global Support or Tier 4: Product Development engineers are searching for a specific log line
within the logs, you should assist them by identifying that log line rather than just providing the logs for the hour requested.

Macros

Typically, in a basic log gathering request situation with no waiting, the Assigned macro is used. The engineer will then escalate the
ticket back to Level 3 when the logs are attached.

Waiting for Customer Input

Another stage that could be used is Waiting for Customer Input. For example, if the field equipment is not available at the time of
the initial information request, the ticket can be temporarily placed here until it is powered on, and the logs become available.

Page 22
MODULE 1: Ticket Stages

Released to Level 1
When a ticket is returned to Level 1 from Level 3 or Level 4, the next stage will depend on the feedback. Note that the following
stages also apply if a ticket is solved at Level 1.

Waiting for Install

As previously described, Waiting for Install is used at Level 2, when a bug that was experienced in the customers current version was
resolved in a later version, or a future release of FrontRunner or DISPATCH. We would request that the customer upgrades their
version of the system.
Once the new version of the application is installed, these types of tickets can be routed to Technical Completion and eventually
Closed by Agent.

Macros

The Waiting for Install macro states <No notes required> however, it is good practice to explain which product and version is
waiting for install, for example “Waiting for install of FrontRunner v3.5.”

Technical Completion / Closed by Agent

The final Level 1 ticket stages are Technical Completion and Closed by Agent. Tier 1 engineers will use these stages when a ticket has
the root cause understood, the fix is in place, and the customer is fully aware of the results. Once these criteria have been met then
the ticket can officially be closed.

Macros

The Technical Completion macros to be completed are:

Operational Problem Statement
Root Cause
Steps to Resolve Issue
Corrective Actions
Related Official Documentation
Fixed In
Closed By Agent

Page 23
MODULE 1: Ticket Stages

Merging Tickets
If the ticket was identified to be a duplicate of another issue from the same region and customer, then a merge can be performed.
Typically, when the ticket is released from Level 2 and a merge is necessary, the Tier 2: Regional Support engineer will request a
merge, identifying the root cause, and the ticket it is to be merged with.
It is then assigned to a Tier 1 engineer who will apply the merge macro and fill out the questionnaire, before submitting the merge
request. The ticket is then merged and closed.
The purpose of the merge is to reduce the overall number of duplicate tickets that display unexpected behavior.

Macros

Note that there is no Merge macro at Level 1 and Level 2, instead a button will become available when a ticket reaches the Assigned
stage.

Oct 18 14:09 Jane Doe [Link]@[Link] (change) from Zendesk Support

Figure 5: Zendesk Merge Button

Page 24
MODULE 1: Ticket Stages

Resources
Useful guides have been created to assist you in your work.

Zendesk User Guidelines

Two documents have been created to assist users with Zendesk tickets. These processing documents provide explanation and
guidance for input, processing, and the general flow of tickets. Both documents are stored on Box:
• AHS Zendesk User Guidelines is designed for all Zendesk users, and is a customer-facing document.
• AHS Zendesk Agent Guidelines is designed for Komatsu internal-use only, and is written for Zendesk ticket agents.
Ticket agents are Komatsu employees and Komatsu distributors.

Task

Spend some time familiarizing yourself with the guides that have been created to assist you in your work:
• AHS Zendesk User Guidelines
• AHS Zendesk Agent Guidelines

Page 25
MODULE 1: Ticket Stages

Page 26
MODULE 2: Field Equipment & Support

MODULE 2: Field Equipment & Support

Page 27
MODULE 2: Field Equipment & Support

Page 28
MODULE 2: Field Equipment & Support

Module 2: Field Equipment & Support

This module will describe the equipment used in the field, their specifications and operating systems, file structure and connection
techniques:

• Field Equipment Connections

• Field Computer
• Radio
• Global Navigation Satellite System (GNSS) Receiver

The module will also describe the tasks you will be called upon to perform on this equipment in your role to support the client.

Learning Objectives

At the end of this module, you will be able to:

• Explain the basic field equipment connections.
• Explain the field computer, its specifications, operating system, file structure, and connection techniques.
• Explain then demonstrate the common field computer tasks you will be required to perform in your role.
• Explain the radio, its operating system, and connection techniques.
• Explain the common radio tasks you will be required to perform in your role.
• Explain the field equipment GNSS receivers, their operating system, and connection techniques, including tunneling
procedures.
• Explain then demonstrate the common field equipment GNSS receiver tasks you will be required to perform in your role.

Assessment

• Complete the online lesson.

• Complete the online assessment.
• Complete the tasks throughout the module.

Page 29
MODULE 2: Field Equipment & Support

Page 30
MODULE 2: Field Equipment & Support

Field Equipment Connections

This module will describe the field computer, radio and GNSS receiver in detail, and the tasks you will be required to perform on
each piece of equipment.
Before we describe each item in detail, it is important to understand the basic connections in an AT and EMV. The first diagram
(below) illustrates the connections made in an AT. The second diagram illustrates the connections made in an EMV:

Figure 6: AT Connections

Figure 7: EMV Connections

Page 31
MODULE 2: Field Equipment & Support

Field Computer
Each location and each piece of equipment (manual or autonomous) on an autonomous mine
site is equipped with a device, usually a PTX‐C, commonly referred to as the field computer.
The field computer is a touch screen device which has a ‘pit display’ in the center, a graphical
representation of the autonomous mine site.
The field equipment service is hosted from each individual field computer and is scripted to
boot upon power up. It manages the interaction between the user via the touch screen and
the FrontRunner server with information being sent from the GNSS receiver that is within the
field equipment. The information is processed by the field computer and sent to the
FrontRunner server over the wireless network.
Figure 8: Field Computer in an EMV cab

Specifications

The table below gives a basic overview of field computer components and their specifications. Detailed specifications can be found
in the PTX-C section (under Hardware) in the Download & Resource Center.

COMPONENTS FIELD COMPUTER SPECIFICATIONS The documents referred to throughout this

module are stored in the Download & Resource
CPU Processor Model ARMv7 Processor Rev 10 Center. As described in the Foundations course:
CPU Processor Cores 4 Pre-version 3.4 is stored on SharePoint:
RAM Storage 1 Gb 1. From the Corporate Departments
dropdown, select Support Services.
SD Card Storage Space 8 Gb 2. Click on Download and Resource Center in
the left-hand menu.
Network Interfaces Eth0 & Eth0:1
3. Navigate to the appropriate document(s).
Turck Cable - Ethernet
Version 3.4 (and later) is stored on Box:
Multiple Power Connectors
Harness Connector Box > EX_FrontRunner for OEMs >
Serial CAN connection for E-Stop Button EX_FrontRunner for DBs >
EX_DownloadCenterStorage
Serial CAN connection for CR Controller

Operating System

Field computers are Linux devices, running a customized version of Debian. Normally the field computer boots from the primary
storage device and runs the FrontRunner application from there. However, the field computer also features a dual-boot recovery
system which allows the machine to boot from the secondary storage device and use a backup image to re-flash the primary storage
device. This means that the field computer can always be restored to a working factory image. The storage devices for a field
computer are CF cards (CompactFlash).
The default username for the field computer is dlog and the associated password is gold. This typically does not change on site.

Page 32
MODULE 2: Field Equipment & Support

File Structure

Field equipment files, including the FrontRunner application, are stored in /home/dlog/frontrunnerV3
The field computer file system is structured differently to most Linux environments, with a non-persistent root partition. This means
that any changes made to files (editing, deleting, etc.) will be reverted when the device is rebooted. For example, files deleted from
/home/dlog/frontrunnerV3 logs will reappear.
The purpose of the non-persistent root partition is to always ensure that we have a base to boot from. The dual-boot recovery
system keeps the internal storage on the field computer as standard while the files stored on the CF card are available for
permanent changes. Another benefit is that this provides a layer of protection against unwanted changes being made to a field
computer in production.
To make permanent changes manually, including deleting files, the alternative path /media/rearoot/home/dlog must be used.

Key Paths

The key paths utilized are:

Live Logs are the logs that the
/home/dlog/frontrunnerV3 is the main FrontRunner application directory. Note currently operating service is writing
that this is a symbolic link (symlink) to a folder for the specific version of FrontRunner to. These logs can be monitored live
installed. by using the tail -f <log name>
/home/dlog/frontrunnerV3-3.2.2-001-ptx is the real directory where command.
FrontRunner is installed. Note that this is only used during installation. For all other tasks Broken Logs are generated and
use the symlink directory. stored here when the service writing
/home/dlog/frontrunnerV3/logs is the location of Live and Broken FrontRunner to the logs is unexpectedly
log files. terminated. This can occur during
service restarts, power cycle events
/home/dlog/frontrunnerV3/logs/<yyyymm> is the location of Archived for vehicles, etc.
FrontRunner log files.
Archived Logs are log files that get
/home/dlog/frontrunnerV3-support/current/ is the FrontRunner support compressed and moved to the
directory. As with the main FrontRunner folder, this is also a symlink to a folder for the defined folder. A cron job process
current release version. Always use the current symlink to ensure the correct tools are that is executed by the field
used. computers OS every hour handles
/home/dlog/tcpdumps/ is the location where packet captures are stored, if enabled. this. Eventually these archived logs
will be permanently deleted from the
field computers storage by another
cron job.

Page 33
MODULE 2: Field Equipment & Support

Connection Techniques

There are three connection techniques: PuTTy, secure shell (SSH), and virtual network computing (VNC). Before we describe these
methods in detail, let’s review the two network interfaces and their IP addresses.

Network Interfaces

Connections can be established to a field computer either locally, via direct physical connection, or remotely over the AHS field
network. The field computer is connected to two networks; therefore, it has two IP addresses:
• LAN (local area network) which only connects the field computer to devices connected to the radio within the field
equipment. The field computer’s default IP for its LAN connection is [Link]. The only way to connect to a field
computer using this address is if you are connected to the field equipment radio, which is the center point of the LAN. You
may also use a Turck cable, with an ethernet terminated end, to connect your laptop directly to the field computer.
Note that the interface name for this device is Eth0:1
• WWAN (wireless wide area network) is the Wi-Fi or LTE network used to connect the field equipment to the supervisory
system’s FrontRunner server. The IP address for this interface is unique to its part of the network. This address is used to
remotely connect to the field computer from the central network and infrastructure.
Note that the interface name for this device is Eth0
While it is often easier to connect remotely, LAN connections are preferred whenever possible because they eliminate the chance of
accidentally connecting to the wrong field computer.

Network Connection Methods

There are three possible methods of connection:

PuTTy
A terminal connection offers a command-line interface and is essential for many
support tasks. A utility like PuTTY (Windows) or SSH (Linux) can be used to connect
to the field computer and provides a remote terminal environment.
Most support situations where you may need to troubleshoot a problem with a
field computer will begin by attempting to connect to it via PuTTy from the
support jumphost or on-site support desktop.
PuTTy defaults to opening to the Session category where it provides fields and
options for configuring your session:
• For a simple process such as connecting to a field computer remotely;
make sure that the SSH radial button is selected, and the port is set to 22.
• If connecting to the field computer remotely using the Wi-Fi network,
enter the IP address of the field computer’s Eth0 interface.
• If connecting to the field computer using the LAN network of the field
equipment, enter the IP address of the field computer’s Eth0:1 interface
([Link]). Figure 9: PuTTy’s Session GUI

Page 34
MODULE 2: Field Equipment & Support

Secure Shell (SSH)

There may be some support scenarios where you do not have PuTTy available, but you do have a Linux-based machine available to
remotely communicate with the field computer. In this type of scenario, you can use some basic SSH terminal syntax to remotely
connect from the Linux-based machines terminal directly to the field computer’s terminal.
Common syntax:
$ ssh user@destination_ip

After pressing Enter, you may be warned before connecting that the host can’t be trusted. Type Yes and press Enter.
The authenticity of host ' destination_ip (destination_ip)' can't be established.
ECDSA key fingerprint is [Link].
Are you sure you want to continue connecting (yes/no)?
You will now be remotely connected to an SSH terminal session of the specified field computer.

Virtual Network Computing (VNC)

VNC can only be used over a local connection and cannot be used remotely over a production Wi-Fi network. VNC was originally
required as part of the installation process, but now is only used for starting the touch screen calibration utility, if it cannot be done
manually. For more information, refer to the FrontRunner Field Equipment Rollout document.

Common Tasks

The common field computer tasks that you will be required to perform are explained in detail in the appropriate version Deployment
Documentation (under Products) in the Download & Resource Center.
The FrontRunner Field Equipment Rollout document contains deployment scenarios and step-by-step instructions for:
• File transfer
• Deploy / Redeploy / Activate
• Maintenance
• Re-flashing
The Administrator Guide contains additional information and step by step tasks, for example:
• Downloading log files
• Setting IP address
• Touch screen calibration
• Loading / Reloading software

Page 35
MODULE 2: Field Equipment & Support

Tasks: Field Computer

Review the PTX-C spec files to ensure you are familiar with the following field computer component specifications:
• CPU Processor Model
• CPU Processor Cores
• RAM Storage
• SD Card Storage Space
• Network Interfaces
• Harness Connectors

If a simulation environment with a physical field computer is available*, spend some time practicing connecting to both network
interfaces:
• WWAN interface: Eth0
• LLAN interface: Eth0:1

If a simulation environment with a physical field computer is available*, spend some time practicing the three network
connection methods:
• PuTTy
• SSH
• VNC

Review the FrontRunner Field Equipment Rollout document to ensure you are familiar with the following tasks:
• File Transfer
• Deploy / Redeploy / Activate
• Maintenance
• Re-flashing

Review the Administrator Guide to ensure you are familiar with the following tasks:
• Downloading log files.
• Setting the IP address.
• Touch screen calibration.
• Loading/Reloading software (as per Rollout documentation, not referencing field VM used in Australia).

*If a simulation environment is not available, do not connect in a production environment to explore!

Page 36
MODULE 2: Field Equipment & Support

Radio
Regardless of whether a site runs an LTE or Wi-Fi network, the current model
of IP radio approved for use is the 8445, manufactured by AVI in Australia.
The AVI 8445 incorporates both the wireless radio component and a network
switch, acting as the network hub for an AHS-equipped field equipment.
The AVI radio acts as the center point for the field equipment
communications. It connects the GNSS receiver(s), the field computer, and
other components, for example, the flight recorder on a LAN used by the
FrontRunner application. As described in the field computer section, the LAN
Figure 10: AVI 8445 Radio is also the preferred network to use when supporting the devices on field
equipment.
The AVI radio also connects the field equipment field computer to the FrontRunner and DISPATCH servers through a wireless
interface. The interface may be a Wi-Fi or LTE network, depending on the site. This wireless interface is also assigned an IP address
and is reachable from the AHS server infrastructure that is hosting the FrontRunner server, DISPATCH servers, and the surrounding
support machines.

Operating System

AVI devices run AVIOS, a proprietary firmware based on OpenWRT. AVIOS releases must be validated by AHS Product Development
before they can be used in production. As AVIOS is Linux-based, some scripts and tools can be executed directly on the AVI 8445.
This can include packet captures, additional logging, watchdogs, or other tools as required.
Always ensure that field radios are configured in accordance with the AHS rollout procedure. It is recommended to export a
configuration template file for each site to ensure all radios are configured consistently and correctly.
Note: For LTE sites, it is essential that the hostname applied to the radio matches the equipment ID in FrontRunner and DISPATCH.
For more information on the configuration of an AVI 8445 radio, detailed specifications can be found in the AVI Radio & Lanpipe
section (under Hardware) in the Download & Resource Center.

Connection Techniques

Like the field computer, the AVI 8445 radio has a local and field IP address:
• The field IP address is specific to each radio and uniquely identifies it on the field network. Refer to your site’s IP allocation
sheet for further information.
• The local IP address is [Link]. Note that before you apply the configuration to an 8445, this local IP address is set to
[Link].
The primary method of connecting to an AVI 8445 is the GUI via a web browser. This can be done locally or remotely by typing the IP
address into the browser address bar and logging in with the site-specific credentials. The web GUI is used to upgrade firmware, load
configuration files, make manual configuration changes, or to check the current status of the radio.
SSH is also available locally and remotely on the AVI 8445 but is only used for specific troubleshooting tasks such as enabling packet
captures.

Page 37
MODULE 2: Field Equipment & Support

Common Tasks

The common radio tasks that you will be required to perform are explained in detail in the Administrator Guide which can be found
in the appropriate version Deployment Documentation (under Products) in the Download & Resource Center:

• Enabling packet captures: Starts a process to monitor specific network traffic going to and from an interface on the radio.
• Downloading packet captures: The process of obtaining packet captures remotely from a radio.
Detailed specifications can be found in the AVI Radio & Lanpipe section (under Hardware) in the Download & Resource Center. These
documents will explain tasks such as:
• Configuring and reconfiguring Wi-Fi & LTE on the AVI radio.
• Troubleshooting an AVI radio.
• Installing a SIM card on an AVI radio.

Tasks: Radio

Review the AVI 8445 Radio spec files to ensure you are familiar with the radio configuration specifications.

Review the Administrator Guide to ensure you are familiar with the following tasks:
• Enabling packet captures.
• Downloading packet captures.

Review the 8445 AVI Radio documents to ensure you are familiar with:
• Configuring Wi-Fi & LTE on the AVI radio.
• Troubleshooting an AVI radio.
• Installing a SIM card on an AVI radio.

Page 38
MODULE 2: Field Equipment & Support

Field Equipment GNSS Receivers

The GNSS receiver used in AHS equipped field equipment is the Topcon MM2. It provides high-
precision GNSS position data and is available in single and dual antenna variations. For AHS, most
field equipment is dual antenna. Single-antenna field equipment are ATs and PPVs.
For high-precision functionality, stable network connectivity to a functional Ground Station,
Monitor, and GNSS application are also required. Without these, the MM2 can only provide
position data in standalone mode, with reduced accuracy.
Figure 11: MM2 Rover Unit

Operating System

The Topcon OS is proprietary and specific to MM2. As with the AVIOS, new releases of the Topcon OS/firmware require validation
before they can be used in AHS.
In addition to the firmware, the MM2 requires a specific configuration file to be applied. This
configuration file is generated during FrontRunner system installation; however, we may need
to use an updated version that the application has not yet generated. This updated
configuration file MM2 CE (109112 & 109113) can be found via the GPS Receivers section
Figure 12: Configuration File Location
(under Hardware) in the Download and Resource Center.
To ensure that the latest firmware file is used, refer to the FrontRunner Master Checklist, which can be found in the appropriate
version Deployment Documentation (under Products) in the Download & Resource Center.

Connection Techniques

Unlike the radio and field computer, the MM2 only has a local (LAN) IP address when installed on a field equipment. For a dual-
antenna model MM2, the primary (master) receiver uses IP address [Link] and the auxiliary (slave) uses [Link].
Single-antenna models only have the primary IP.
The MM2 also features a serial connection. The application used to connect to the MM2 is the Topcon Receiver Utility (TRU). It can
be used over a network or serial connection, although a network connection is recommended. For remotely connecting from outside
the field equipment LAN, you must use the tunneling technique described below.

Tunneling

While the MM2 only has a local IP address, it is possible to connect remotely using a technique called tunneling. Tunneling is when a
connection is made from a remote support machine to the field computer, which forwards a local TRU connection to the remote
device.
This is an essential technique for investigating GNSS issues on a production site. Follow the steps on the next page to complete a
basic tunnel configuration.

Page 39
MODULE 2: Field Equipment & Support

In this configuration, we will assume the support workstation is a Windows PC

with PuTTY installed.
To start, we must configure PuTTY:

1. Open PuTTy, expand the SSH category, and click Tunnels.

1
2. Configure the port forwarding by setting the Destination to
[Link]:8002, the Source Port to 3333, and ensure that the Local
and IPv4 buttons are selected.

3. Click the Session category and enter the IP address of the field
computer of the field equipment with the GNSS receiver. Click Connect.
This terminal must remain open to allow for the TRU application to establish a
connection using this tunnel.

2
4. Finally, open TRU, then open a network connection to localhost:3333
using password modular.

This example illustrates the most

common tunneling scenario. 4
Further tunneling examples can be
found in the appendix at the end of
the module.
Figure 13: Tunneling Steps

Page 40
MODULE 2: Field Equipment & Support

Common Tasks

The common GNSS Receiver tasks you will be required to perform are to:
• Check the pos type and satellite count in TRU.
• Download logs.
• Configure and reconfigure GNSS receivers.

Check the Pos Type and Satellite Count in TRU

This task is used to verify that the receiver can
communicate with satellites. It also ensures that it is
receiving corrections from the Ground Station.
To check the position count in TRU:
1. Open the TRU application and start a network
connection to the receiver in question. Figure 14: TRU Status Icon

2. Once connected, click on the Status icon.

3. The Status window will appear, displaying the
position type, current coordinates, the receivers
current satellite count, and other signal
information such as PDOP.

Figure 15: TRU Status Window

Download Logs

This task is used to download logs, noting that letters

correspond to UTC hours. The logs are required for analysis
when GNSS issues are experienced.
To download logs:
1. If the vehicle is available on the wireless network,
open TRU on the support jumphost and begin a Figure 16: TRU File Explorer Icon
tunneled SSH session to the receiver in question.
(Refer to the previous Tunneling section for
connection instructions.)
2. Once connected click on the File Explorer icon.
3. In the File Explorer window click on the Files tab to
access the logs for this receiver.
4. To download a file, right click on the file and select
Download.

Figure 17: Right Click on the file

and select Download

Page 41
MODULE 2: Field Equipment & Support

5. Select the location to download the file to your support

jumphost. The file download will begin, and a progress bar will
appear. Once complete, a .tps file will be available in the
download location specified.

Figure 18: Select the Figure 19: A download

download location progress bar appears

Configure and Reconfigure GNSS Receivers

This procedure is common in production: Often new field equipment will be introduced to the fleet which requires the configuration
of receivers. The configuration guide MM2, E112, and Net-G5 Firmware Upgrade Procedure is referenced in the FrontRunner Field
Equipment Rollout-Rollback Procedure, which can be found in the appropriate version Deployment Documentation (under Products)
in the Download & Resource Center.

Tasks: Field Equipment GNSS Receiver

Review the updated MM2 CE file to ensure you are familiar with the new generated configuration file.

Review the FrontRunner Master Checklist to ensure you are familiar with how to check that the latest Topcon/OS firmware file is
used.

Review the appendix at the end of the module in the student guide for additional specific tunneling scenarios.

Review the GNSS receiver configuration guide MM2, E112, and Net-G5 Firmware Upgrade Procedure.

If a simulation environment is available*, ensure you are familiar with the following tasks:
• Tunneling a GNSS receiver through a field computer.
• Checking the Pos Type and Satellite Count in TRU.
• Downloading logs.
• Configuring the GNSS receivers.
*If a simulation environment is not available, do not connect in a production environment to explore!

Tasks: General

Additional module tasks will ensure you are familiar with field equipment. Shadow your mentor to:
• Tour an EMV and inspect the following hardware components and how they are connected: Field computer, radio and GNSS
receiver.
• Tour an AT and inspect the following hardware components and how they are connected: Field computer, radio, GNSS
receiver, flight recorder and SMN controller.

Page 42
MODULE 2: Field Equipment & Support

Appendix: Additional Tunneling Scenarios

Tunnel through PTX-C

To create tunnel to GPS antenna with connection to wireless network:

1) Configure putty connection to Field Computer device using ssh-> Tunnels settings to create a port forward from Destination
Port [Link]:8002 to source port 3333 (Local, IPv4)
2) Use Tru to open a network connection to localhost:3333 with password modular.
3) if 2 gps, connection between local 3334 and remote [Link]:8002 can be added to the same putty session to connect
to the second antenna

Tunnel Windows (with TRU) -> Linux -> PTX-C -> GPS

If there is a "hop" (e.g.- you have connection to FRMASTER, but not wireless network):
1) Configure putty to open a tunnel with Destination localhost:8889 and source 3333
2) in that session, open ssh to the desired Field Computer with command like-
ssh dlog@FieldComputerIP -L 8889:[Link]:8002
NOTE: In this case, to connect to second antenna, the recommended procedure is to Disconnect Tru form the first, "exit" the ssh
session on the hop (e.g.- frmaster) and then use command like:
ssh dlog@FieldComputerIP -L 8889:[Link]:8002
After this is done, the same setting in TRU will connect to the second antenna.

Automate Tunnel with a Hop [Helpful for Layer 3 Systems]

1) In FrontRunner Server, create new user “TruTunnel” [as su, useradd TruTunnel; passwd TruTunnel]
In /home/TruTunnel/.bashrc, add the following at the end:
read -p “Enter Equipment IP:” Field_IP
read -p “Antenna 1 or 2?” antenna
ssh dlog@${Field_IP} -L8889:[Link]${antenna}:8002
read -p “SSH Tunnel open. Hit enter to close and exit”
exit
2) Then, procedure for open this tunnel will only be ssh TruTunnel@FRMaster and enter passwords as prompted, which can
be saved to putty session (see attached). With this, using TRU even with layer 3 can be very easy.
Optional improvement- bash script can read database and print case statement to copy paste into file, so that ‘Field_IP’ can be like
“T8” instead of “[Link]”, which can simplify and reduce chance of error. In which case, it might as well add user too, so whole
setup process can be ‘run this script’, then the tunnel user with ssh access can be setup.
TRU settings to connect like this will be to connect by network to local port 3333, no user, password modular, which will be saved in
TRU after first use.

Page 43
MODULE 2: Field Equipment & Support

Page 44
MODULE 3: Troubleshooting & Investigation

MODULE 3: Troubleshooting & Investigation

Page 45
MODULE 3: Troubleshooting & Investigation

Page 46
MODULE 3: Troubleshooting & Investigation

Module 3: Troubleshooting & Investigation

This module is split into two lessons.

The first lesson will describe the various methods you should use when troubleshooting:
• Identify and understand symptoms.
• Check for communication loss.
• Check power and connection status.
• Review logs.

The second lesson will describe investigation procedures: If troubleshooting fails to solve the issue, further investigation may be
required:
• Playback analysis and recording.
• Log gathering.
• Building a timeline of events.

Learning Objectives
At the end of this module, you will be able to:
• Explain the methods used to troubleshoot an issue: First steps to identify and understand, then how to check for
communication loss, power and connection status, and review logs.
• Explain the methods used to investigate an issue: Playback analysis and recording, log gathering, and building a timeline of
events.
• Demonstrate troubleshooting and investigating issues in a simulation environment and non-critical tickets.

Assessment
• Complete the online lessons.
• Complete the online assessment.
• Complete the tasks at the end of the lessons.

Page 47
MODULE 3: Troubleshooting & Investigation

Page 48
MODULE 3: Troubleshooting & Investigation

Lesson 1: Troubleshooting
The purpose of troubleshooting is to understand the current problem, to solve the issue. This involves understanding the symptoms
being experienced, checking for communication loss, power and connection status, and reviewing logs.

Symptoms

The first step is to identify and understand the issue symptoms:

• What exceptions are in the Action List?
• What does the operator see? What are they experiencing?
• What was being attempted? What was the operator doing at the time of the problem?
• What is the expected behaviour? What should be happening in normal circumstances?
Note that although you will use the operator’s description in your initial troubleshooting; do not assume that the operator/user
understands what they are seeing or describing. Do not jump to a predetermined solution based on their description. The issue may
be very different to the operator complaint, for example, “I have comms loss” could in fact be that their GNSS antenna is broken.
The operator’s initial description, however, will usually guide you in the right direction. They may highlight some Action List
exceptions or warnings. They may explain that their central controller application disconnected from the server, or that a field
equipment had some unexpected behavior occur, etc. Be sure to make a note of their description and then begin troubleshooting.

Procedures

The first step is to check for communication and power/connection status. Only after these items have been ruled out, should you
start reviewing logs.

Check for Communication Loss

After identifying the equipment involved, checking communication to a device is an easy first step to perform:

Find the unit in Mineview and check its status:

• Exceptions/Warnings in the FrontRunner Mineview/Controller’s Action List will indicate specific
issues.
FrontRunner Mineview • Received Signal Strength Indication (RSSI) status in the equipment grid and the Last POS Update
timestamp: If the timestamp is incrementing, it means the server is communicating with the field
computer.
• POS Status: Status1 and Status2 of the Equipment Status window will indicate GNSS quality.
Ping Test Conduct a Ping test to the field computer/radio/GNSS hub. Note that pinging to the GNSS hub is only
possible when connected to the field equipment LAN.

TRU Check the TRU access/tunnel configuration via a PuTTY session.

Contact the site network team if you suspect an overall network issue in a particular area: The Central
Network
Controller is likely to have knowledge of existing troublesome areas.

Depending on the results of the communications loss tests:

• If the device is not reachable on the network, there may be a hardware or power failure.
• If the device is reachable on the network, then it is assumed that the device is powered on, and communication is as
expected for that device.

Page 49
MODULE 3: Troubleshooting & Investigation

Check Power & Connection Status

The next step is to check the power and connection status of the device(s) you suspect is causing the issue. Note that the device may
not be immediately accessible; the truck could be in maintenance for example or in an area not covered by AHS Wi-Fi / LTE. It is also
worth noting that Tier 1: Onsite Support and Tier 2: Regional Support engineers may not be required to physically replace hardware
on a field equipment; this will often fall to the distributor.

Physical Damage
First check for any visible signs of physical damage. If damage is found, the repair and work process will differ depending on the
component, and in some instances, the customer may be responsible. Remember to take photographs of any visible damage to
attach to the ticket.

Power Indicators
The power indicator and lighting will depend on the device:

DEVICE INDICATOR

Field Computer Blue temp light and the screen is backlit.

Radio Blinking green link lights and green power indicator lights.
MM2 GNSS Green power and link lights and multicolour antenna 1 and 2 status lights.
Auxiliary (AUX) Box New style AUX boxes have indicator lights.
Note that older models do not have indicator lights.
Harness Master Consoles Indicator light panels on the side of the console.
Note that Harness Master consoles are site-specific.
Charge Guard A green light should be visible inside the AUX box of light field equipment kits.
Note that Charge Guard models are site specific.

Page 50
MODULE 3: Troubleshooting & Investigation

Source / Switch Power

Use the table below as a checklist:

ITEM CHECK
Voltage Source and switch power are both 12 V* and anything less than 10v will trigger a power down:
• Confirm that the source power is constant. The source connection should be located at a fuse panel or
the field equipment battery.
• Switch power should engage with ‘key-on’. The source will usually be at fuse/circuit panel tied into the
switched power source (anything that comes on in the field equipment when the key is switched to the
‘on’ position).
Grounding Points Should have:
• Good conductivity: Ensure surfaces are clean and not painted.
• Tight connection, which will not become loose during operations.
Wiring Runs Can fray, rub-through, or deteriorate over time. Inspect for exposed copper and signs of wear/damage,
particularly:
• In high traffic areas, for example, under interior body work and inside the door jambs of light field
equipment.
• At transition points where wiring runs through material or into a cab/compartment.
*Note that all source/switch components require 12 V power to operate, plus or minus one or two volts, except for the older style
Ethernet radios which require constant 24 V.

Power Timer
The power timer controls the power distribution/switch power activation throughout the AHS system but is a common failure point.
It will often ‘blow’ in colder temperatures: Check for the recognizable ‘burnt electrics’ smell.

Embedded Log File

IF THEN
The string SIGTERM appears then the power loss was due to the switch (check the power timer and switch power
source/wiring).
The string SIGTERM does not appear or there is gibberish/garbage data in the log file, then source power was lost, or the field
computer application crashed.
Note that if the Minemobile log is a fragment, check towards the end of the log.

Page 51
MODULE 3: Troubleshooting & Investigation

Review Logs

If communication loss and power/connection status failed to identify the issue, then review the logs of the device(s) you suspect are
causing the issue to identify any of the following key indicators:

LOG ACTION
Check for repetitive messages, particularly the E (error) messages, which are the most
FRMaster
important and may hint at what is causing the error/exception.
Search for the action string to show the log lines relating to operator actions, for example,
Field Computer FrontRunner
button/screen presses, etc.
Watch the playback dat file with informational windows open, to better understand the
Playback
situation/described symptoms, for example, the equipment grid, AT status menu, etc.
With GNSS issues, it is always good practice to review tps logs for root cause indications, for
example, the status of the receiver, number of tracked satellites, age of corrections, etc. This
GNSS Receiver
would apply to any impacted GNSS receivers; the GNSS Ground Station and Monitor and
equipment receivers.
These logs, stored on FRMASTER, will show User Datagram Protocol (UDP) communication
TCPDumps (prominent protocol) between FRMASTER and the fleet. In the event of a communication loss,
it may be worth opening the logs in Wireshark to review the time of the communication loss.

Severity

Depending on the severity of the issue, immediate action may need to be taken:

If troubleshooting has led you to a specific field equipment that is causing the issue, consider requesting that the operator:
• Restart their equipment.
• Remove the equipment from the AT area if the issue persists, so that hardware can be investigated.
SAFETY: When restarting or leaving the AT area, operators should follow standard procedure per operator handbooks to protect
themselves, the equipment, and those around them. Standard procedures include obstacles, isolation areas, field equipment
escorts, etc.

If the issue is more widespread and is impacting multiple equipment or the entire fleet, consider coordinating a services restart with
the Central Controllers / Dispatchers. Only perform this step if you are certain that the root cause is not stemming from equipment
in the field. A restart of services will not resolve an issue that stems from a field equipment.

Escalate to Level 3

After troubleshooting, the next step is investigation. However, if the issue is severe and cannot be contained, it should be
immediately escalated to Level 3 (Tier 3: Global Support). For example, if the immediate actions taken by the on-site team to contain
the issue are not successful, and ATs are unable to move material, then the issue should be immediately escalated to Level 3 using
the emergency support telephone line. Your mentor/supervisor will provide you with the telephone number in case of a production
emergency that requires immediate escalation.

Page 52
MODULE 3: Troubleshooting & Investigation

Task: Troubleshooting

If a simulation environment is available*, spend some time familiarizing yourself with troubleshooting procedures:

• For server components such as FRMASTER, E-Stop, GNSS Ground Station, GNSS Monitor, and NTP.
o Connecting to each device.
o Finding and reviewing logs for the service in question.

• For field equipment such as the field computer, radio, and GNSS receivers:
o Connecting to each device.
o Finding and reviewing logs for the service in question.

• Demonstrate troubleshooting tickets: Your mentor will provide tickets/issues for you to troubleshoot.

*If a simulation environment is not available, do not connect in a production environment to explore!

Page 53
MODULE 3: Troubleshooting & Investigation

Lesson 2: Investigation
If troubleshooting has not solved the issue, further investigation may be required. Investigation procedures include analyzing and
recording Playbacks, gathering and reviewing logs, and building a timeline of events.

Playbacks

The FrontRunner Playback is a useful investigation tool, which is also used to record new Playbacks to support an investigation.

Playback Analysis

Playback provides a historical interactive Mineview (1) showing events as they unfolded within the timestamp of the playback file. It
is a user-friendly tool which allows you to zoom in and out and move the view using the mouse. It provides:
2. A Truck Status window as per the Central Controller view.
3. An Action List, just as the Central Controller will have viewed live.
4. Playback options, such as playback speed, pause and fast forward/rewind (in minutes or seconds).
5. Most importantly, a behind the scenes view of events and tasks sent from the supervisory system, field equipment
operators, and Central Controllers.

1
4

Depending on the type of issue that is being investigated, it may be worth taking screenshots of the playback and pasting them to
your analysis on the Zendesk ticket to better visualize the issue.
Playbacks are used to understand the timeline of events. When starting your historical investigation, review the playback and note
timestamps of major events shown in system events window (5) and when pertaining Action List (3) events occur and disappear.
After visualizing the events in the playback and noting the important timestamps, compare the playback timestamps to the
FrontRunner server logs at those timestamps.

Page 54
MODULE 3: Troubleshooting & Investigation

Playback Recording

When recording playbacks, you should always:

• Focus on the specific unit(s) of interest.
• Ensure the playback is good quality; at least 1920 x 1080.
• Include a grid so that users can judge approximate distances; usually a 10-meter grid.
• Show the AT speed, recorded at 1x speed, unless otherwise requested.
• Limit the amount of ODS shown over the previous 24 hours.
• Use OBS software.

Severity

When recording playbacks for customer review, consider what is being requested, and why: Safety related issues are high priority,
therefore, playback recording, and analysis should be conducted immediately for customer review. If the issue is not safety
related, informational playbacks can be produced later, when the ticket is being reviewed.

Log Gathering

Log gathering is an important part of your role to solve tickets, and to assist Tier 3: Global Support engineers when a ticket is
escalated to Level 3.

Log Types & Locations

The log type and its location will depend on the application: FrontRunner, DISPATCH, the FrontRunner/DISPATCH adapter, network,
or operating system.

FrontRunner
The following FrontRunner Service Logs can be found in /home/mms/frontrunnerV3/logs on the FRMASTER virtual machine:
• frontrunner_server-<hostname>_YYYY-MM-DD_HH-MM-SS_XXXX.dbg is the FrontRunner server Java service
log file.
• [Link] contains information output from the bin/frontrunner command and output that did not
make use of the logback component when the Java VM was started.
• FR_process_event.log tracks high level statistics for the FrontRunner Java process executed on that machine, for
example, detected crashes, time of crash, and the next attempt to start the server.
• [Link] contains information relating to garbage collection events that occur on FRMASTER.
• gc_server.log contains descriptions of the garbage collector install and current memory and configuration.
• management_server- FRMaster_YYYY-MM-DD_HH-MM-SS_XXXX.dbg is the services health management log file
(used when Product Development is troubleshooting performance problems). These files contain statistics for moving
averages and various counters.
• stats_server- FRMaster_YYYY-MM-DD_HH-MM-SS_XXXX.dbg contains truck action status event information on
a 5-second basis. The information stored in this file is also stored in the frontrunner_server log file.
The FrontRunner Playback Log is found in /home/mms/frontrunnerV3/playback on the FRMASTER VM:
• AHS_LOG_YYYYMMDD_HHMMSS.dat

Page 55
MODULE 3: Troubleshooting & Investigation

The following E-Stop Service Logs can be found in /home/mms/frontrunnerV3/logs on the E-Stop desktop:
• frontrunner_emergencyapp-<hostname>_YYYY-MM-DD_HH-MM-SS_XXXX.dbg is the Emergency Stop Java service
log file.
• management_emergencyapp-<hostname>_YYYY-MM-DD_HH-MM-SS_XXXX.dbg is the services health management
log file (used when Tier 4: Product Support is troubleshooting performance problems). These files contain statistics for
moving averages and various counters.
• gc_emergencyapp.log contains information relating to garbage collection events that occur on the E-Stop desktop.
• [Link] contains information output from the bin/FrontRunner command and output that did not
make use of the logback component when the Java VM was started.
• FR_process_event.log tracks high level statistics for the emergency app Java process executed on that machine, for
example, detected crashes, time of crash, and the next attempt to start the server.
• stats_emergencyapp-<hostname>_YYYY-MM-DD_HH-MM-SS_XXXX.dbg is typically blank.
The following GNSS Ground Station Service Logs can be found in /home/mms/FrontRunnerV3/logs on the GNSSGS / NTP
desktop:
• FrontRunner_gpsgs-<hostname>_YYYY-MM-DD_HH-MM-SS_XXXX.dbg is the GNSS Ground Station Java service log
file.
• management_gpsgs-<hostname>_YYYY-MM-DD_HH-MM-SS_XXXX.dbg is the services health management log file
(used when Product Development is troubleshooting performance problems). These files contain statistics for moving
averages and various counters.
• gc_emergencyapp.log contains information relating to garbage collection events that occur on the gpsgs services
desktop.
• [Link] contains information output from the bin/FrontRunner command and output that did not
make use of the logback component when the Java VM was started.
• FR_process_event.log tracks high level statistics for the gpsgs Java process executed on that machine, for example,
detected crashes, time of crash, and the next attempt to start the server.
• stats_gpsgs-<hostname>_YYYY-MM-DD_HH-MM-SS_XXXX.dbg is typically blank.
The following Field Computer Logs can be found in /real_home/mms/FrontRunnerV3/logs on the field computer:
• [Link] contains information output from the bin/FrontRunner command and output that did not
make use of the logback component when the Java VM was started.
• FrontRunner_minemobile-mde_YYYY-MM-DD_HH-MM-SS_XXXX.dbg is the FrontRunner Minemobile Java service log
file for the field computer.
• management_minemobile-mde_YYYY-MM-DD_HH-MM-SS_XXXX.dbg is the services health management log file (used
when Product Development is troubleshooting performance problems). These files contain statistics for moving averages
and various counters.
• gc_minemobile.log contains information relating to garbage collection events that occur on the field computer.
• [Link] tracks touch screen presses and is controlled by an optional variable in [Link].
• stats_minemobile-mde_YYYY-MM-DD_HH-MM-SS_XXXX.dbg is typically blank.
The following Field Computer Logs must always be gathered from the equipment in question:
• Minemobile and Management Logs: Sort by the Last Modified value in WinSCP, to avoid potential errors in filenames. The
Last Modified timestamp will show the last time that log was written to, so a timestamp of ‘16:00’, for a Minemobile log for
example, will contain data for the hour ending at 16:00h. Gather all partial logs, in addition to compressed hourly logs.
• Field Computer OS Logs: Gather Journalctl logs, however, note that these logs are not always consistent. They are reset on
a power cycle.
• Garbage Collector Logs: Gather if a garbage collector event is suspected to have impacted performance. This is rare.

Page 56
MODULE 3: Troubleshooting & Investigation

GNSS Receiver
The GNSS receiver logs are tps files that contain an hours’ worth of data from the receiver. They can be downloaded via TRU.
If GNSS/POS issues are the likely cause of an issue, gather logs from GNSS hub(s). Note that the GNSS logs timestamp will be in UTC;
therefore, you need to be aware of conversion to your local time.

FrontRunner/DISPATCH Adapter
The C:\Program Files\Modular Mining Systems, Inc\FrontRunner-Dispatch Adapter\log contains:
• [Link]-HHMMSS which consists of informational logs regarding the items being
sent to the FrontRunner server and their latency to ship.

DISPATCH
• C:\mms\dsp\bin\Log contains logs of all services running in the machine. Typically, if DISPATCH logs are needed for an
investigation, it is worth taking the entire log folder and compressing it.
• Program Files\intellimine\mms\ScreenCapture#.png contains the installation screenshots for reference.
• The Transaction and Exception tables in the DISPATCH reports provide detailed information of the DISPATCH operations
and tasks that DISPATCH, and the dispatchers perform.

Network
The /home/mms/Logs on FRMASTER contains:
• Tcpdump_YYYY-[Link] contains packet capture information. These logs should always be provided
when investigating a network issue.
For the radio logs use the Web GUI – Status – System Log:
• Copy and paste the logs into a text file.
• Note these logs are not persistent and are cleared when the radio is power cycled.
The following Ethernet radio logs are located in /home/mms/FrontRunnerV3-support/current/mobile/logs on the field
computer:
• [Link] contains status information regarding the Ethernet radio CDS (Collision Detection
System) monitor task on the Ethernet radio.
• [Link] contains status information regarding the health of the Wi-Fi network interface.
Contains value such as RSSI and latency.
• [Link] tracks any resets that occur for the ER CDS (Ethernet Radio Collision Detection System) task.
Logs from the radios themselves are not consistent, as they too are lost on a power cycle. If required, ensure that you gather these
logs before a power cycle is performed. Note that radio logs are not particularly useful, so this type of log may not be required.

Operating System
For OS log files:
• Use the journalctl command on Linux machines to obtain the kernel logs. Note that the output needs to be copy/pasted
in a notepad file.
• With touch screen logs, the touchscreen input event logger needs to be enabled.

Page 57
MODULE 3: Troubleshooting & Investigation

Logs Existence Timeline

The Logs Existence Timeline is used for cron job clean ups and ring buffers. The table below details the FrontRunner sub system logs
and their locations.

Over
Logging Average File Files last
Location File name Written Usage
Level Size frequency up to
(Y/N)

Topcon GNSS Receiver logs

Rover Devices: rover_MMDDa.tps 2-3 weeks

Ground Station Devices: base_MMDDa.tps - based
Topcon Receiver File System Normal 8 MB every hour N Checking GPS data
Note: The alphabetical reference is for hour of the day in on
UTC time, e.g., a = 00:00 ; x = 24:00 memory

FrontRunner Service Logs and Playbacks

/home/mms/frontrunnerV3/playback AHS_LOG_YYYYMMDD_<PID> 10MB 15 mins N 120 days Play back of FR Mine View
Management_<service>-<hostname>_YYYY-MM-
/home/mms/frontrunnerV3/logs/YYYYMM 3MB 1hr N 180 days FR System Logs
DD_HH_<PID>.dbg
/home/mms/frontrunnerV3/logs/YYYYMM stats_<service>-<hostname>_ YYYY-MM-DD_HH_<PID>.csv 100KB 1hr N 180 days FR System Logs
frontrunner_<service>-<hostname>_ YYYY-MM-
/home/mms/frontrunnerV3/logs/YYYYMM 700KB 1hr N 180 days FR System Logs
DD_HH_<PID>.dbg
/home/mms/Logs tcpdump_YYYY-MM-DD_<PID>.pcap 120 MB 1hr N 30 days FR System Logs

Field Computer Service Logs

/home/dlog/frontrunnerV3-3.2.0-053- management_minemobile-mde_ YYYY-MM-

INFO 1.5MB 1hr N 180 days FR Embedded System Logs
ptx/logs/YYYYMM DD_HH_<PID>.dbg
DEBUG
TRACE
/home/dlog/frontrunnerV3-3.2.0-053- frontrunner_minemobile-mde_ YYYY-MM-
INFO 10 KB 1hr N 180 days FR Embedded System Logs
ptx/logs/YYYYMM DD_HH_<PID>.dbg
DEBUG
TRACE

Field Computer Support Tools Logs

/home/dlog/frontrunnerV3- Checking RSSI signal of

er-monitor-snmp-YYYYMMDD 700KB Continuous Y 180 days
support/current/mobile/logs radio
/home/dlog/frontrunnerV3-
er-monitor-cds- YYYYMMDD 1KB Continuous Y 180 days Checking CDS of system
support/current/mobile/logs
/home/dlog/frontrunnerV3-
er-reset- YYYYMMDD 1KB Continuous Y 180 days Watch dog reset command
support/current/mobile/logs

Flight Recorder Logs

Flight Recorder File System <AT_ID>_YYMMDD_HOUR_MINUTE_SECOND.gz 5MB 1hr Y 7 days Truck Controller Logs

Other Time Sensitive Logs

Other important logs that should be tracked are:
• Linux kernel logs, which are overwritten after a reboot.
• Garbage collection hprof logs, which are overwritten after a reboot.

Page 58
MODULE 3: Troubleshooting & Investigation

Log Levels

Log levels are applied to the [Link] file for whichever service the log level pertains to. Within the [Link] file, modify
the line; <root level=”INFO”>. Change INFO to any of the log levels listed, depending on the need.
Typically, INFO provides enough detail. Note that if the log level is heightened, then the service logs will be removed at a faster rate
because their size will be larger.
Log levels are as follows:
• OFF means no logging is taking place.
• INFO is basic logging.
• DEBUG is a more complete log level.
• TRACE typically is a very wordy log, which should be used with care as it may affect performance if enabled.
Each logger listed below provides specific detail for the thread that it is named after. Typically, we do not need to modify the loggers
that are enabled or disabled. Using the default logger configuration is recommended unless Product Development recommends
enabling a specific logger in the [Link] file.
The available loggers are:
• [Link] • [Link]
• [Link] • [Link]
• [Link] • [Link]
• [Link] • [Link]
• [Link] • [Link]
• [Link] • [Link]
• [Link] • [Link]
• [Link] • [Link]
• [Link] • [Link]
• [Link] • [Link]
• [Link] • [Link]
• [Link] • [Link]
• [Link] • [Link] equipmentcontrols
• [Link] • [Link]
• [Link] • [Link]
• [Link] • [Link]
• [Link] • [Link] [Link]
• [Link] • [Link] [Link]
• [Link] • [Link] [Link]
• [Link] • [Link] [Link]
up • [Link] [Link]
• [Link] • [Link]
ds • [Link]
• [Link] • [Link]
• [Link] order
• [Link]

Page 59
MODULE 3: Troubleshooting & Investigation

Identifying Broken Logs

To identify broken logs:

• FrontRunner Server logs will be in the main logs folder: /home/mms/FrontRunnerV3/logs uncompressed. A broken log
will have an incorrectly labeled timestamp that will stand out from the other logs in this directory. Broken logs are not
automatically compressed by the cron job task nor moved into their MMYYYY folder.
• Field Computer FrontRunner logs will be in the main logs folder: ~/real_home/FrontRunnerV3/logs not
uncompressed. A broken log will have an incorrectly labeled timestamp that will stand out from the other logs in this
directory. Broken logs are not automatically compressed by the cron job task nor moved into their MMYYYY folder.
• GNSS logs end with a letter to denote hour of the day. The receivers’ logs will have a trailing 3-digit number after the letter
in the log name if there was a fragment/power loss during that hour, for example, [Link] [Link]

Windows Event Viewer

If there is an issue within the Windows operating system, it may be worth capturing and reviewing the
Windows Event Viewer logs. To access, press the Windows key on your keyboard and search Event
Viewer. Typically, the most informative logs are in the Windows Logs folder:
• Application: For services related issues, e.g., Microsoft SQL server.
• Security: For user login information.
• System: For information related to crashes and operating system backend processes.
Figure 20: Windows Event Viewer

VMWare Information

Use the VM menus and charts listed on the

next page to check for VM issues.
Issues and Alarms, Performance, and Tasks
and Events are accessed by:
1. Left-clicking the VM in question. 2
2. Selecting the Monitor tab in the
main window of vCenter.

Figure 21: vCenter Monitor Menu

Page 60
MODULE 3: Troubleshooting & Investigation

Issues and Alarms

Within the Issues and Alarms drop-down menu:
• All-Issues displays all VM exceptions that occurred. These types of events are typically worth noting
and reviewing.
• Triggered Alarms displays only triggered alarms for the selected VM. Alarms are notifications that are
activated in response to an event or a set of conditions.

Performance Graphs
If there is a suspected issue with the VM performance, it may be worth looking at the VMs’ vCenter
performance chart. Select the:
• Overview window to view statistical graphs for the VM’s CPU, Memory, Memory Rate, Disk, and
Network. You can adjust the timeframe by selecting Custom Interval in the Real-Time drop-down
menu. Figure 22: Advanced
Dropdown Menu
• Advanced menu shows more detailed statistics and larger graphs for each of the resources. Again, you
can adjust the time frame using the Real-Time menu and changing it to a Custom Interval.

Tasks and Events

Within the Tasks and Events drop-down menu:
• Tasks displays all VM actions dating back to the last reboot of the vCenter.
• Events displays all actions performed to the VM, whether it was user-performed or an automated task, for example a
vMotion event. The Events link can be very informative when investigating why a VM was slow or locked up.

Log Gathering Tools / Methods

Each type of log has a specific tool / log gathering method:

• Field Computer Logs: WinSCP
• GNSS Logs: TRU’s log download tool via a tunnelled or local connection.
• Windows Workstation Logs: Windows directory, RDP Drive pass through.
• Linux Workstation Logs: WinSCP
• AVI Radio Logs: AVI webpage or WinSCP
• Flight Recorder Logs: Collected by a connection to the AT’s LAN.
Refer to Lesson 4 of the Foundations (Level 1) course Administration module (Module 6) for more information about file transfer.

Page 61
MODULE 3: Troubleshooting & Investigation

Issues & Log Types

The type of logs gathered will depend on the issue being experienced. Refer to the chart below for a basic introduction to which logs
(rows) should be gathered based on the high-level issue description (columns).

Organization

It is important to keep logs organized and informatively labeled:

• When gathering logs, you must place them together in one zipped folder with the Zendesk ticket number as the folder
name.
• Always ensure that correct naming and organization conventions are followed, as there is no way to tell which EMV a log
file originated from.
• When sending/posting logs, ensure field computer logs are placed together in a folder with the unit’s name, and nest that
inside the larger folder with ticket number label, before zipping.
The table below illustrates the recommended log bundle and sub folder structure:

Page 62
MODULE 3: Troubleshooting & Investigation

Timeline

Your investigation should contain a detailed timeline of events:

• Gather timestamps from phone call logs, emails, chat messages, log files, playback screenshots, warning/exception
messages, form completion, etc.
• Ensure that the timeline is laid out in the Zendesk ticket, with specific timestamps of when the behaviour or event in
question was observed. Playback screenshots are an excellent tool for this.
• Reducing investigation times helps focus on the specific event. Have timestamps down to the millisecond if possible.
• Do not include log lines in your timeline that are not relevant to the situation. Irrelevant log lines may confuse and
potentially obscure the relevant information for the next support engineers.

Task: Investigation

Spend some time familiarizing yourself with the investigation procedures:

• Assist in the playback analysis for a non-critical ticket.
• Ensure that you are familiar with logs and their locations for the various services: FrontRunner, DISPATCH, the
FrontRunner/DISPATCH adapter, network, and OS.
• If a simulation environment is available, demonstrate investigating issues. Your mentor will provide tickets/issues for
you to Investigate. (If a simulation environment is not available, do not connect in a production environment to
explore!)

Page 63
MODULE 3: Troubleshooting & Investigation

Page 64
MODULE 4: Installation & Configuration

MODULE 4: Installation & Configuration

Page 65
MODULE 4: Installation & Configuration

Page 66
MODULE 4: Installation & Configuration

Module 4: Installation & Configuration

This module will describe the installation and configuration of the essential hardware components of AHS-equipped field equipment,
for example, ATs, PPVs, and other equipment such as Fuel Bays and Crushers. While the physical installation is typically completed
by a third party, Komatsu engineers are responsible for the further configuration of components. The module will also describe the
configuration of the FrontRunner and DISPATCH systems servers, when adding new equipment.

Learning Objectives

At the end of this module, you will be able to:

• Explain the procedures for measuring, profile recommendations, and configuring field equipment in DISPATCH and
FrontRunner, including any region/customer/site-specific procedures.
• Explain the installation checklist and configuration procedures for the GNSS receiver, radio, and field computer,
including any region/customer/site-specific procedures.
• Explain re-configuration procedures and the procedures for installation and configuration of non-standard equipment,
including any region/customer/site-specific procedures.

Assessment

• Complete the online lesson.

• Complete the online assessment.
• Complete the tasks throughout the module.

Page 67
MODULE 4: Installation & Configuration

Page 68
MODULE 4: Installation & Configuration

Important Notes
Physical Installation

This module assumes that the physical installation of AHS components has already been completed. The actual installation
procedures for field computers, GNSS antennas, and AHS kits are not described in this module.

Site-Specific

The processes described in this module depend heavily on the region, the customer, and site-specific procedures. This module is a
general guide; you must ensure that you follow the correct regional, customer and/or site-specific policies and processes,
particularly safety procedures. Your mentor will explain any region/customer/site-specific procedures throughout the module.
Spaces have been provided in this student guide for you to record this information.

Documentation

Most of the processes described in this module have detailed documents The following documents are referred to in this
with step-by-step procedures to assist you. module. They are stored in Box and can be
This module is a general guide; you must ensure that you follow the accessed via the Download and Resource Center:
detailed steps in the appropriate documents.
This student guide and the online course do not replace documentation. DEPLOYMENT DOCUMENTATION
• FrontRunner Equipment Parameter
Deployment Documentation Specification (in the Specifications section)

As described in the Foundations (Level 1) course; Deployment In the Rollout-Rollback Documentation section:
Documentation is stored in the Download and Resource Center. • FrontRunner DISPATCH Rollout Procedure
• FrontRunner Field Equipment Rollout-Rollback
Pre-version 3.4 is stored on SharePoint:
Procedure
1. From the Corporate Departments drop-down select Support • FrontRunner Master Checklist
Services.
2. Click on Download and Resource Center in the left-hand menu.
HARDWARE INSTALLATION DOCUMENTATION
3. Select the version you require.
4. Scroll down to Deployment Documentation. Hardware Guides:

Version 3.4 (and later) is stored on Box: • Central System

• PTXC Systems
Box > EX_FrontRunner for OEMs > EX_FrontRunner for DBs >
• 3410 Radio and Uni-GPS
EX_DownloadCenterStorage
• 3410 Retrofit
• Ethernet Radio and Uni-GPS
Hardware Documentation • AHX10-to-PTXC Field Replacement
• AHX10 Systems
Follow the steps above to access Deployment Documentation but scroll
• Other FrontRunner Hardware
down and click on the link: Hardware Installation Documentation.
EX_FrontRunner for OEMs > EX_FrontRunner for DBs > Hardware Forms:
EX_DownloadCenterStorage > Customer Material > • FrontRunner Hardware Configuration Form
Version-agnostic > Hardware Installation Documents
• FrontRunner Installation/Audit Sign-Off Form

Page 69
MODULE 4: Installation & Configuration

Page 70
MODULE 4: Installation & Configuration

Equipment Configuration
This section of the module will describe the procedures for measuring and configuring field equipment for the first time, in the
FrontRunner and DISPATCH system servers. Your mentor will explain any additional site-specific procedures. Record any site-specific
information in the space provided after each section.

Physical Measurements

Field equipment needs to be physically measured in detail to ensure that safety parameters are accurate. The specific
measurements required will vary based on the equipment type. For example:
• A light vehicle, such as a PPV (Pit Patrol Vehicle), requires only two measurements: The height of the antenna and the
distance from the antenna to the furthest part of the vehicle.
• An articulated grader, however, requires measurements to define the length and width of the front and rear portions, the
width of the blade, the maximum articulation angle, etc.
Field equipment measurements are typically taken, along with photographs for evidence and context, and then collated in a
Measurement Report. This report is region/site-specific. It is used by the individual or team responsible for generating a profile
recommendation: The measurements taken are configured in the field equipment model profile within the FrontRunner controller.
The engineer(s) responsible for performing these tasks may vary amongst sites and customers. Some regions have their Tier 1
engineers perform these measurements; other regions have the distributor perform measurements.
Your mentor will explain who is responsible for field equipment measurements, and where the Measurement Reports are located at
your site / in your region. They will also explain any variations in site-specific procedures and documents. Record this information in
the space provided below.

Site-Specific Procedure

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

Page 71
MODULE 4: Installation & Configuration

Profile Recommendations

A profile recommendation will be made from the Measurement Report. The recommendation will consider the physical dimensions
of the field equipment, the current profile in FrontRunner (if it exists), other field equipment using that profile (if any), and other
factors such as system limitations or customer preference.
Safety envelopes are generated relative to the field equipment reference point. However, this
point is not always the center of the field equipment, therefore it is important to ensure
reference points are used consistently. For example, the profile for an articulated loader must
use the point of articulation as the reference point, whereas a rigid dozer profile can use the
center of the field equipment or a fixed physical point.
Recommendations must be made as listed in the FrontRunner Equipment Parameter
Specification. Your mentor will explain any additional site-specific procedures. Record this Figure 23: Safety envelope and reference
point of a Front-End Loader
information in the space below.

Site-Specific Procedure

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

Review & Approval

The profile recommendation must be reviewed and approved before the field equipment can be used autonomously. Generally, the
customer provides this approval, however, site-specific procedures may vary. Your mentor will explain your site-specific procedure.
Record this information in the space below.

Site-Specific Procedure

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………

Page 72
MODULE 4: Installation & Configuration

DISPATCH

After the profile dimensions are known and the field equipment is fully equipped with the FrontRunner kit, the equipment can be
configured in DISPATCH and then FrontRunner.
DISPATCH has a Model and Equipment Record: The Model is created through the DISPATCH
Configuration Utility before the Equipment record can be created. Once the Model exists in
DISPATCH, an Equipment Record can be created from any of the following equipment utility
windows: Auxiliary, Shovel, or Truck.
Figure 24: DISPATCH Equipment
Models Icon Creating the equipment record includes selecting the Model from a drop-down list. Additionally,
an entry must be added to the OMS host files to ensure DISPATCH can communicate with the
field equipment. This involves editing a text file on the DISPATCH Application and OMS servers.
This procedure is described in detail in the FrontRunner DISPATCH Rollout Procedure.

Figure 25: DISPATCH Equipment Models Table

Page 73
MODULE 4: Installation & Configuration

FrontRunner

Once the equipment model is created in DISPATCH, a corresponding profile must be manually created in FrontRunner.
The FrontRunner profile name must match the DISPATCH Model name exactly, as described in the Foundations (Level 1) course. If
the profiles do not match exactly, the field equipment under that model in DISPATCH will not integrate to FrontRunner.
An equipment profile is the set of values that define the safety and productivity items that allow a field equipment to operate
autonomously. Equipment profiles were described in detail in the Foundations (Level 1) course. To recap:
• Equipment profiles exist in FrontRunner. The equivalent term for “Equipment profile” in DISPATCH is “Equipment Model”.
• Equipment profiles are shared between all field equipment configured to use that profile.
• The equipment profile name must match the equipment model as defined in DISPATCH for the field equipment to be
recognized and be available in FrontRunner.
Each field equipment also has several parameters specific and unique to that field equipment. These include the GNSS offsets, IP
address, the equipment name. Depending on the equipment type, there may be other options, such as enabling an optional foot
switch or ProVision features, teleoperation features, etc.
A full list of safety and productivity parameters are listed in the FrontRunner Equipment Parameter Specification.

Example

If a site had three Komatsu WA900 loading units, all using the same profile “Komatsu WA900”, they will all have the same safety and
productivity parameters as defined in the profile. Each field equipment, however, will have an individual ID, network address, and
GNSS antenna offsets.
For a complete list of values and profile types refer to the FrontRunner Equipment Parameter Specification.

Tasks

Spend some time familiarizing yourself with the documents referred to throughout the Equipment Configuration section of the
module, particularly:
• The physical measurement of equipment in the Measurement Report.
• Equipment profile recommendations in the FrontRunner Equipment Parameter Specification.
• The DISPATCH equipment configuration procedure in the FrontRunner DISPATCH Rollout Procedure.
• FrontRunner safety and productivity parameters in the FrontRunner Equipment Parameter Specification.
Spend some time familiarizing yourself with any region/customer/site-specific procedures referred to throughout the Equipment
Configuration section of the module, particularly:
• Equipment measuring and the Measurement Report.
• Profile recommendation procedures.
• Review and approval procedures.

Page 74
MODULE 4: Installation & Configuration

Field Equipment Hardware Installation & Configuration

As previously mentioned, the actual installation of field equipment hardware is typically performed by a third party.
Komatsu engineers will then have a list of further physical items they need to complete when hardware is installed on a new field
equipment. This procedure is described in detail in the FrontRunner Hardware Configuration Form.
After performing these items, a checklist is used to audit the installation and configuration. This procedure is described in detail in
the FrontRunner Installation/Audit Sign-Off Form.
In addition to following these documents, you must always follow site-specific procedures. Your mentor will explain any relevant
site-specific procedures for hardware installation and configuration. Record this information in the space below.

Site-Specific Procedure

………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………

Documentation

The devices listed on the next page all have individual specific Hardware Installation Guides. Additionally, step-by-step configuration
procedures are listed in the FrontRunner Field Equipment Rollout-Rollback Procedure.

Page 75
MODULE 4: Installation & Configuration

GNSS Receiver Configuration

Topcon GNSS receivers (E112 and MM2 models) are configured using the Topcon Receiver Utility
(TRU). The TRU is used to set the IP address of the receiver and upgrade the firmware, as necessary.
Then the AHS-specific configuration files can be loaded through TRU. These configurations require a
network or serial connection to a laptop.

Figure 26: MM2 Rover Unit

Radio Configuration

As of FrontRunner 3.4, two models of AVI radio are supported. The 3410 supports Wi-Fi only,
while the 8445 supports Wi-Fi and LTE configurations. In all cases, a site and model-specific
configuration file is used.
A laptop and ethernet cable are required, however, unlike the GNSS receivers, special
software is not required. All AVI configuration is done via a web browser interface. Use the
browser-based configuration utility to set the IP address of the radio (Wi-Fi only), upgrade
firmware if required, and load the site-specific configuration file. Figure 27: AVI 8445 Radio

Field Computer Configuration

Loading the FrontRunner software onto a field computer requires a laptop connection with an ethernet cable, typically through the
network port located on the AHS kit box.
1. Firstly, the field computer needs to be re-imaged. This wipes the internal memory and restores it to a pre-configured state.
2. Then the field computer IP address is configured, and the application can be installed.
3. Finally, any regional customizations are applied. These may include workarounds or containments for known issues. Your
mentor will explain these to you in person. Record any regional procedures in the space provided below.
Note that in some regions a VM is used to automate these common tasks from a field laptop. Your mentor will identify if this is
applicable to your site. Record this information in the space below.

Site-Specific Procedures

………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………

Page 76
MODULE 4: Installation & Configuration

Master Checklist

Once installation tasks are complete, the FrontRunner Master Checklist should be completed for each piece of field equipment. This
consists of several items to check and note down, then the final verification step is to log into the field computer and confirm that
the equipment shows a green POS status.
Both the checklist and the functional verification are essential and must not be skipped.
Site specifics may vary. Your mentor will explain your site-specific procedure. Record this information in the space below.

Site-Specific Procedure

………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………

Tasks

Spend some time familiarizing yourself with the documents referred to throughout the Field Equipment Hardware Installation &
Configuration section of the module, particularly:
• Hardware Forms: FrontRunner Hardware Configuration Form and FrontRunner Installation/Audit Sign-Off Form.
• Individual Hardware Installation Guides and FrontRunner Field Equipment Rollout-Rollback Procedure configuration
documents for the GNSS Receiver, Radio and Field Computer.
• The field equipment verification procedure in the FrontRunner Master Checklist.
Spend some time familiarizing yourself with any region/customer/site-specific procedures referred to throughout the Field
Equipment Hardware Installation & Configuration section of the module, particularly:
• Any site-specific hardware installation and configuration procedures.
• Any region-specific field computer configuration customizations (where applicable).
• Any site-specific VM field computer configuration procedures (where applicable).
• Any site-specific variations to the final verification.

Page 77
MODULE 4: Installation & Configuration

Support Tasks
This module describes the initial installation and configuration of hardware items. Your role is also to provide support for existing
hardware, for example, re-configuring and/or replacing the field computer (and other hardware items) are common tasks.
Always treat the re-configuration process as if it were a new installation:
• Complete all steps as listed in the FrontRunner Field Equipment Rollout-Rollback Procedure.
• Complete the FrontRunner Master Checklist after configuration.

Other Field Equipment

Other field equipment installation and configuration may be required, for example for the Crusher and Fuel Bay field computers.
These installations may be very similar to field equipment; including the radio and power supply connections, however, there may
also be some key differences. Crusher field computers, for example, have no radio or GNSS receiver and require manual editing of
the internal network adapter. For all non-standard equipment installations, refer to the Hardware Installation Guides. For all non-
standard equipment configurations, refer to the FrontRunner Field Equipment Rollout-Rollback Procedure.
At some sites, for example in Australia, you may be able to refer questions to the project engineer who requested the installation.
Your mentor will identify if this is applicable to your site and/or explain your site-specific procedure. Record this information in the
space below.

Site-Specific Procedure

……………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………

Tasks

Spend some time familiarizing yourself with the documentation referred to in the Other Equipment section of the module:
• Non-standard equipment installations in the individual specific Hardware Installation Guides.
• Non-standard equipment configurations in the FrontRunner Field Equipment Rollout-Rollback Procedure.
Spend some time familiarizing yourself with any region-specific non-standard installation procedures (where applicable).

Page 78
MODULE 5: Simulator Installation & Support
AHS

module 6: Administration

This module is split into four lessons……

Lesson 1: Operating Systems
• Virtualization Basics
• Windows OS
• Windows Server OS
• Linux OS
Lesson 2: FrontRunner Files
Lesson 3: DISPATCH Files

MODULE 5: Simulator Installation & Support

Lesson 4: Other

Learning Objectives

Page 79
MODULE 5: Simulator Installation & Support
AHS

Page 80
MODULE 5: Simulator Installation & Support
AHS

Module 5: Simulator Installation & Support

This module will describe the purpose of FrontRunner and DISPATCH simulators, and their invaluable role in training, testing and
development. It will also describe simulator installation options for all services in a FrontRunner and DISPATCH environment. At the
end of the module, you will learn about some of the simulation scenarios and the simulator support tasks you may be required to
perform in your role.

Learning Objectives

At the end of the module, you will be able to:

• Explain the purpose of simulators to train, test, and develop products.
• Explain the FrontRunner and DISPATCH simulation services installation options.
• Explain customer and test/development simulation scenarios, including any site-specific procedures.
• Explain simulator support tasks: Updating databases and adding equipment, including any site-specific procedures.

Assessment

• Complete the online lesson.

• Complete the online assessment.
• Complete the tasks throughout the module.

Page 81
MODULE 5: Simulator Installation & Support
AHS

Page 82
MODULE 5: Simulator Installation & Support
AHS

Important Notes

Site-Specific

The processes described in this module have some site-specific variations in procedures. This module is a general guide; you must
ensure that you follow the correct site-specific policies and processes, particularly safety procedures. Your mentor will explain any
site-specific procedures throughout the module. Spaces have been provided in this student guide for you to record this information.

Documentation

Most of the processes described in this module The following documents are referred to in this module. They are stored in Box
have detailed documents with step-by-step and can be access via the Download and Resource Center:
procedures to assist you.
Simulator Rollout-Rollback documents:
This module is a general guide; you must ensure
that you follow the detailed steps in the • FrontRunner Application Rollout-Rollback Procedure Simulation
appropriate documents. • FrontRunner Field Equipment Rollout-Rollback Procedure Simulation
This student guide and the online course do not There are no specific Simulator Rollout-Rollback documents for DISPATCH. Use
replace documentation. the following document located in Rollout-Rollback Documentation instead:
• FrontRunner DISPATCH 6.6.8 Rollout Procedure

As described in the Foundations (Level 1) course; Simulator Rollout-Rollback Documentation and Rollout-Rollback Documentation is
stored in Deployment Documentation in the Download and Resource Center.

Pre-version 3.4 is stored on SharePoint:

1. From the Corporate Departments dropdown select Support Services.

2. Click on Download and Resource Center in the left-hand menu.
3. Select the version you require.
4. Scroll down to Deployment Documentation.

Version 3.4 (and later) is stored on Box:

Box > EX_FrontRunner for OEMs > EX_FrontRunner for DBs > (Release Notes / Rollout Docs / SPEC Files)

Page 83
MODULE 5: Simulator Installation & Support
AHS

Simulator Uses
Simulation environments are important for both Komatsu and for the customer. They are flexible environments that allow valuable
training, testing, and development to be conducted in a safe manner:

Training

One of the main purposes of a simulation environment, particularly for customers, is training. Simulation environments allow new
users to practice using the FrontRunner and DISPATCH applications in a safe non-production environment. They teach controllers
how to navigate through the FrontRunner and DISPATCH applications and field operators how to use the field computer for the
equipment or location they will be operating.
Customers typically have a standard simulation There are opportunities for advanced training environments such
environment on site that is completely virtual. This as those provided by Immersive Technologies. Immersive
environment is standard amongst all customer installs. simulators are aimed at equipment operators. They replicate a cab
of multiple vehicle types, surrounded by large flat screen monitors
Simulators are also used by Komatsu to train internal that gives the user a “real life” feel. Operators can practice loading
support personnel, who complete the same application trucks in a shovel or driving through a virtual pit in a light vehicle
training as the field users. Deployments can also be for example. Ask your supervisor if Immersive Simulator training
simulated, for support personnel to practice installing the opportunities are available in your region.
various components of both FrontRunner and DISPATCH.

Testing

Another valuable purpose of a simulator is for Product Support engineers to perform test cases to reproduce unexpected behaviors
that have arisen in a production environment. The benefit of reproducing issues using a simulator is to investigate the sequence of
events that caused the unexpected behavior, in a safe non-production environment.
Simulator testing is generally used by Tier 3: Global Support and Tier 4: Product Development, however, some regions have
dedicated support simulators and test benches that allow Tier 1: Onsite Support and Tier 2: Regional Support engineers to conduct
their own test cases.
If your region does not provide a simulation environment to perform testing, talk to your supervisor to request a license for a
VMWare Workstation Player. This application allows for a user to host virtual machines locally using their laptops resources.

Development

Simulators are also used for development purposes, generally at Tier 4: Product Development. These software developers are
continuously upgrading and improving products and releasing new versions of FrontRunner and DISPATCH.
Tier 1: Onsite Support and Tier 2: Regional Support also have opportunities to enhance day-to-day processes through customized
scripts. Development is typically led by a regional engineer who has a problem to solve and will use their simulation environments to
test these scripts. Note that any scripts developed by an employee in a non-developer position must be validated and approved
using the expedite approval process before being used in a production environment.

Page 84
MODULE 5: Simulator Installation & Support
AHS

Simulation Services
This section of the module will describe the various installation options available to you in both the FrontRunner and DISPATCH
simulation environments.

FrontRunner Simulation Services

Module 4 of the Foundations (Level 1) course described the various services that the FrontRunner system requires to function in
both a production and simulation environment. These are the FrontRunner services options available to you in a simulation
environment:

FrontRunner Server

The FrontRunner server process is hosted on a VM in both a production and simulated environment. Acceptable deviations and
differences between the production and simulation VMs are:
• The resources (i.e., the CPU, RAM, disk space) allocated to the simulation VM may be lower than that required in a
production FRMASTER, depending on the purpose of the simulator.
• The .properties files within the /home/mms/frontrunnerV3/conf/ directory will contain some additional strings
that enable or disable certain functions for the FRMASTER server. You may also find that you need to configure certain IPs
and ports a little differently when operating in a reduced simulation environment. Refer to the FrontRunner Application
Rollout-Rollback Procedure Simulation document for more information on these specific properties.

Network Time Protocol (NTP)

The NTP is an OS service that has some flexibility as to where it is hosted and used. Note that NTP is only required where there are
multiple VMs hosting FrontRunner services outside of the FrontRunner server VM, such as virtual field computers or the
FrontRunner controller. Typically, it is recommended to start an NTP server locally on the FrontRunner server VM and sync the other
service VMs to the FrontRunner server. The time sync can also be conducted manually, however, it is recommended that an NTP
service is hosted within the simulation environment to allow for automated time syncing.

Global Navigation Satellite System (GNSS) Ground Station

In a production environment, the GNSS Ground Station service requires Topcon receivers, antennas, and connecting infrastructure
to the host physical desktop. In a simulation environment this physical infrastructure is not required; the software developers have
created a GNSS simulation tool, typically hosted on the FRMASTER VM.
The screenshot (right) illustrates the GNSS simulation tool. Note the name is
“CORE_SERVICES”. This indicates that the GNSS simulation tool is currently
simulating the Ground Station services. It can also be used to simulate
manual vehicle GNSS devices. Note that the:
• StartDummyGps button starts the GNSS simulation. Until it is
pressed, the tool will not simulate the GNSS device.
• StopDummyGps stops the GNSS simulation.
When simulating the GNSS Ground Station service, you are not required to
press any other tool buttons besides the start and stop dummygps buttons. Figure 28: GNSS Simulation Tool
To configure and simulate the GNSS Ground Station service, refer to the
step-by step instructions in the FrontRunner Application Rollout-Rollback Procedure Simulation.

Page 85
MODULE 5: Simulator Installation & Support
AHS

Emergency Stop Service (Controller)

The Emergency Stop service for a controller is another optional simulator feature. It
can be enabled and used as per a production environment if the hardware is
available. This would require a desktop computer configured with the correct OS,
with an Emergency Stop Button connected to it. However, there is no way to
simulate an Emergency Stop Button press. Typically, simulators do not use a real
Emergency Stop Button unless a specific test case calls for the hardware.
To disable the Emergency Stop Button, refer to the step-by step instructions in the
Figure 29: E-Stop connected to configured desktop FrontRunner Application Rollout-Rollback Procedure Simulation. This configuration is
conducted on the [Link] file on the FRMASTER server.
Field Computer

Field computers are an essential part of a FrontRunner simulator. There are three options when following the FrontRunner Field
Equipment Rollout-Rollback Procedure Simulation document:
• Virtual: The most common option is ‘virtually’, where the field computer service is hosted from a Linux VM, rather than
having an actual field computer present. Virtual field computers:
o Do not require individual configured IPs and multiple field computer simulators can run on one VM.
o Behave as an actual field computer would, but without the wireless infrastructure or physical components.
o Have some limitations: A VM can only host so many field computers. You may need to have a dedicated VM
hosting the Field Computers and their corresponding GNSS simulators.

• Simulated: The next option is to use a field computer device (for example a PTX-C) and connect it to the infrastructure
hosting the FRMASTER and DISPATCH VMs. This method is referred to as ‘simulated’, as it does not require a wireless
infrastructure or GNSS receivers to host the service and connect to an FRMASTER server. This option is useful for testing but
is not an option for customer simulators as they do not purchase field computers specifically for this purpose. Typically,
customers do not provide field computer devices for a simulation environment.

• None: The final option for simulating a field computer is referred to as ‘none’. This option is used in deployments when
installing a production field computer. However, it is only available in fully integrated test facilities such as the Komatsu
Arizona Proving Grounds (AZPG) and the Suncor Mine Testing environment. This option requires that the field computer is
connected to the CR controller (if installed on an AT), GNSS receivers and radio. The Modular Mining quality assurance
department has a ‘simulated CR controller’ that may also allow their field computers to run as ‘none’.

Field GNSS

The GNSS simulators for virtual and simulated field computers are the same scripts used to host the GNSS Ground Station simulator.
However, the process of starting a vehicle is slightly different: In the command to start the vehicle simulator, you must specify the
number of vehicle antennas, and the vehicle ID. Then once the simulator is up and running the same general buttons used for the
Ground Station apply. There are some additional useful buttons not described in the GNSS Ground Station section above:
• SET is used to update the variables listed in the center of the window. To modify, enter in the appropriate values in the
fields to the right of the variable and press SET.
• GET retrieves a preconfigured list of variables from a saved [Link] file.
• SAVE Position saves the current GNSS simulator options and variables to a [Link] file retrieved via the GET button.
• CLEAR resets all variables to default. The buttons on the right side of the window are used when simulating vehicles.
Note that the GNSS simulators are only required for manual vehicles. ATs in a simulator navigate according to the center of the road
and do not require a GNSS simulator.
Follow the link from the FrontRunner Field Equipment Rollout-Rollback Procedure Simulation document for step-by-step instructions.

Page 86
MODULE 5: Simulator Installation & Support
AHS

Emergency Stop (Field Computer)

As previously stated, there is no way to simulate an Emergency Stop Button connected to a virtual field computer. The only two
options available for a field computer’s dedicated Emergency Stop Button are to:
• Use the “simulated” or “none” option to allow for an Emergency Stop Button to connect to the real device.
• Add some lines to the [Link] file where the virtual field computer is being hosted to disable the
watchdog and timeout checks for the Emergency Stop Button. These properties are the same as mentioned previously in
the Emergency Stop section for the Controller service.
Refer to the FrontRunner Field Equipment Rollout-Rollback Procedure Simulation document for further information.

DISPATCH Simulation Services

The DISPATCH simulation environment is similar to a production environment, particularly when integrated with FrontRunner: The
application, OMS and Microsoft SQL services are hosted on VMs, and most configurations still apply. The main differences occur with
the ability to condense all those services into one VM.
There is no specific Simulator Rollout-Rollback document for DISPATCH; follow the FrontRunner DISPATCH 6.6.8 Rollout Procedure
document instead.

DISPATCH Application Services

The DISPATCH application services are hosted and installed as they would be in production; on a VM. As per the other DISPATCH
VMs, one difference is the resources allocated to the VM.
The other main difference for the application services is within the client packages that are required to start some services: Because
of licensing restrictions, it is not possible to start the services without a mms_allow key. This key simulates a client package and is
stored within the DISPATCH installation file structure on the application machine. It is important to note that a client package is still
required in a simulation environment, however a mms_allow key is also required to be placed in a specific folder within the
DISPATCH installation files.

DISPATCH OMS Services

The DISPATCH OMS services are hosted exactly as they would be in production; on a VM. As per the other DISPATCH VMs, the main
difference is the resources allocated to the VM. Other differences include, how the OMS hosts files are created; field computers in a
simulated environment still need individual IPs, but these IPs do not actually need to be allocated.

DISPATCH Database

In most cases, the DISPATCH database is hosted exactly as it would be in production environment. The only differences that may
occur is either reduced VM resource allocation, or that the database may be hosted in the same VM as other DISPATCH services.

Page 87
MODULE 5: Simulator Installation & Support
AHS

Tasks:

Spend some time familiarizing yourself with the documents referred to in this section of the module:
FrontRunner Application Rollout-Rollback Procedure Simulation document, particularly the:
• Specific FRMASTER properties.
• Configuration and simulation of the GNSS Ground Station service.
• Emergency Stop (controller) button disable.
FrontRunner Field Equipment Rollout-Rollback Procedure Simulation document, particularly the:
• Field Computer options: Virtual, Simulated and None.
• Field GNSS simulation procedure.
• Emergency Stop button (Field Computer) options.
FrontRunner DISPATCH 6.6.8 Rollout Procedure document.

Page 88
MODULE 5: Simulator Installation & Support
AHS

Simulation Scenarios
As some of the previous sections described, different installation scenarios are used when deploying simulation environments.
Remember that all the services listed need to be considered when configuring or maintaining a simulation environment. The
following scenarios are commonly found throughout the internal support roles and customer sites:

Customer Simulation Environment

Each customer should have a simulation environment configured within their AHS infrastructure that is segregated from their
production environment. This simulation environment is used to perform operational tasks and test designs before deploying a
concept to a production environment. This VM may also be used for training purposes.
Customer simulation environments typically consist of a:
• FRMASTER VM hosting the FrontRunner server process, and the GNSS Ground Station process which contains an up-to-date
copy of the production database. Note that some customers may have automated database transfer processes in place.
Your mentor will explain these site-specific processes. Record this information in the space below.
• Equipment VM that is typically a cloned copy of the above VM. This VM needs to have some properties updated to point to
the FRMASTER VM. It gives the customer an environment to simulate virtual Field Computers and their GNSS simulators.
• FrontRunner Controller workstation that does not have an Emergency Stop Button enabled.
• DISPATCH Application service VM to host the application services.
• DISPATCH OMS service VM to host the OMS services.
• DISPATCH SQL service VM to host the Microsoft SQL database that is an up-to-date copy of the production database.
• DISPATCH Client workstation.

Site-Specific Procedure

……………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………

Page 89
MODULE 5: Simulator Installation & Support
AHS

Testing & Development Simulation Environments

Testing and development environments will vary depending on the requirements of the test cases being performed or the
development taking place. Many factors need to be considered when deciding which simulation environment is appropriate, for
example: Is DISPATCH integration required? Is any specific hardware necessary? Are there any specific network needs that a
simulator is limited by?
The most common scenarios are:
• Standalone FrontRunner environment: This environment is not integrated with DISPATCH services. Typically, all of the
following FrontRunner services are hosted from one VM:
• FrontRunner server
• GNSS Ground Station simulator
• Virtual Field Computers
• Field GNSS simulators
• FrontRunner Controller
Other services are not needed but may be configured if required for testing or development.

• DISPATCH and FrontRunner integrated environment: This test environment has the same services as the standalone
FrontRunner environment but is integrated with DISPATCH services, which may be installed either in one VM or across
three separate VMs. It is still a completely virtual environment, which should be configured when there is a need to
reproduce a FrontRunner and DISPATCH integration issue. It is also an ideal environment for training and support practice.

• Production-Like DISPATCH and FrontRunner environment:

This final environment will also vary depending on hardware
availability. Its purpose is to deploy a simulated replica of a
production environment, which would ideally include all
aspects of a production environment, even a haul truck.
The best example of this type of environment is the Arizona
Proving Grounds (AZPG) which provides the most realistic
example of a production environment. Another example that
is not as complete as AZPG is the deployment test bench
located in the Product Support development lab. This
environment attempts to replicate as many features of a
production environment as possible without having any real
equipment available.
Figure 30: Simulated Central Control at AZPG

Tasks:

Spend some time familiarizing yourself with site-specific processes, specifically the:
• Customer simulation FRMASTER VM and any automated production database transfer processes.

Page 90
MODULE 5: Simulator Installation & Support
AHS

Support Tasks
This section of the module describes some of the basic simulator support tasks you will be required to perform in your role.

Update Customer Simulation Databases

In a customer simulation environment, the FrontRunner and DISPATCH databases become outdated, compared to those used in
production. Therefore, we need to regularly update the simulation environment with a recent copy of the production databases.
A script has been developed and validated that automates this transfer for the customer. The script must be executed by a qualified
Tier 1 engineer who has been trained and thoroughly understands the procedure. This process is site-specific; your mentor will
explain the procedure to you. Record your site-specific procedure in the space below:

Site Specific Procedure

………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………

Page 91
MODULE 5: Simulator Installation & Support
AHS

Add Equipment

Another common support request will occur when new equipment is added to the database, either via the automated production to
simulation transfer script, or through a user manually adding new equipment in DISPATCH and FrontRunner.
Adding equipment in DISPATCH is the same procedure as per a production environment:
• Ensure the equipment profile exists.
• Then add the new equipment using the specific equipment utility.
• Once the equipment is created, the profile can be added, and other basic DISPATCH configurations can be applied.
When the equipment is added to DISPATCH it will also migrate to FrontRunner through the FrontRunner DISPATCH adapter. This will
be automated, as per production, however, further configuration is required: A properties file on the FrontRunner server must be
edited to include simulated GNSS antenna positions for the manual vehicles. This [Link] file should be
edited on the FrontRunner server VM. Note that this file exists on other FrontRunner installed Linux VMs; however, those files are
not applicable and should not be modified.
Customized scripts have been created to expedite the modification of this file. The scripts query the current FrontRunner database
for any new equipment added and then populate the [Link] file with the proper antenna strings.
The procedure to add equipment to a simulation environment is site specific, your mentor will explain the process to you. Record
your site-specific procedure in the space below:

Site Specific Procedure

………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………

Tasks:

Spend some time familiarizing yourself with site-specific support task procedures:
• Updating the customer simulation databases.
• Adding equipment to the database.

Page 92
MODULE 6: Hardware Validation & RMA
AHS

MODULE 6: Hardware Validation & RMA

Page 93
MODULE 6: Hardware Validation & RMA
AHS

Page 94
MODULE 6: Hardware Validation & RMA
AHS

Module 6: Hardware Validation & RMA

This module will describe the quality control we undertake to validate and test hardware to ensure it meets system requirements,
and the quality assurance we offer our customers via the Return Merchandise Authorization (RMA) process. Warranties, damaged
hardware, and the spare part inventory are described at the end of the module.

Learning Objectives

At the end of this module, you will be able to:

• Explain hardware validation procedures, the resources utilized to test, and hardware failure documentation requirements.
• Explain the general RMA procedure and your client-specific variations.
• Explain the rules of the spare part inventory and where part numbers can be found.

Assessment

• Complete the online lesson.

• Complete the online assessment.
• Complete the tasks throughout the module.

Page 95
MODULE 6: Hardware Validation & RMA
AHS

Page 96
MODULE 6: Hardware Validation & RMA
AHS

Definitions
Before we begin, lets define some of the terms used in this module:

Quality Control & Assurance

This module describes the quality control we undertake and the quality assurance we offer our customers. What is the difference
between quality control and quality assurance?
• Quality Control is the validation and testing of our hardware to ensure it meets requirements.
• Quality Assurance ensures that the quality of our hardware is maintained via the Return Merchandise Authorization (RMA).

Consumables & Non-Consumables

The warranties and spare parts sections at the end of the module describes consumables and non-consumables. What is the
difference between consumables and non-consumables?
• Consumables are items which are consumed, i.e., bought on a regular basis, used, and replaced.
• Non-Consumables are capital goods and items which deteriorate over time.

Page 97
MODULE 6: Hardware Validation & RMA
AHS

Page 98
MODULE 6: Hardware Validation & RMA
AHS

Hardware Validation & Testing

The purpose of hardware validation is to test the hardware specifications against Note that this module describes the
FrontRunner system requirements. Depending on Tier 1 resources and the hardware validation and testing for field
contract with the client, specific tests are performed to verify that hardware equipment. The supervisory system is also
meets system specifications. validated and tested when a new version is
Tests are also performed when a hardware item is deemed faulty and requires installed on site. This process is described in
checking before a field repair is attempted, and/or checked to confirm the failure the Deployment Support course.
before it is sent to Return Merchandise Authorization (RMA).

AHS Hardware Family Page

The AHS HW Family SharePoint page contains

the test procedures for all AHS hardware.
As shown in the image (left), the page contains a
title / image for all required hardware items.
Select the item you are testing to view the
specific documentation.

To access: Login to SharePoint and search

AHS HW Family.
Or navigate to the Welcome to Global
Support Improvement Home Page, select
Global RMA & Incoming Inspection Support
Page, then Modular AHS Hardware Family.

Figure 31: The AHS HW Family page

Depending on the hardware item, sections on the item page include:

• Test Procedure Documents: Used by the Global Hardware team to test
incoming devices from RMA and manufacturer.
• Global Notifications: Documents created post release that are used to
inform of issues, defects, and other notices.
• Miscellaneous Drawings and Work Instructions: Ensure you scroll down
to view Troubleshooting Guides and Other Support Sites for additional
documents and links.
The item page also contains information about the hardware and software
components for the particular hardware assembly, including:
• Support Software & Version: Right click to open online links.
• Device Firmware & Software: List of the installed hardware’s firmware
and software. Note that this is not a full list of FrontRunner software.
• Spare Part List: Defines part numbers for the spare parts kit that is used
to replace parts for the hardware assembly. Figure 32: PTX-C page example

Page 99
MODULE 6: Hardware Validation & RMA
AHS

Documenting Hardware Failure

The Tier 1 engineer should prepare detailed documentation of the failure, including how the part failed, and any deviation in the
initial installation of the part.

Document Part Failure

The Tier 1 engineer should provide a detailed history of how the part failed, including:
• Specifics of the failure:
o The Zendesk ticket.
o Observations/documentation from the operator and/or Tier 1 engineer.
o Previous fails/repairs/complaints on that specific part.

• Common part failures: Zendesk is used to track most hardware failures at customer sites, therefore, this is a good place to
start. Your mentor will explain if there are any additional site-specific tracking tools, record this information in the space
below.

• Seasonal part failures: Including seasonal failures ensures that estimating the recommended spares inventory for the
forthcoming season is accurate and that the appropriate number of parts is ready to be shipped from the RMA department
in Tucson. It also assists in the hardware design process, highlighting areas that could/should be improved for future
component iterations.

• Data analytics of parts usage and the uptime before failure, i.e., the age of part on failure: Analyze if components are
reaching their recommended life spans or are prematurely failing. Trending fails over time, or a failure pattern analysis can
influence restock decisions and future hardware development.

Site Specific Procedure

………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………

Page 100
MODULE 6: Hardware Validation & RMA
AHS

Document Deviations in Installation

The Tier 1 engineer should also provide, where applicable, documentation on any deviation from the standard / recommended
installation procedure for the failed part. An installation audit can be used for this purpose. Deviations also need to be explained /
rationalized in a pre-configuration or similar document.
Note that client sign off is mandatory for all deviations, as the client is responsible for any risks associated with, or caused by, this
deviation.

Tasks

Review the AHS HW Family SharePoint page to ensure that you are familiar with the following documents and links:
• Test Procedure Documents
• Global Notifications
• Miscellaneous Drawings and Work Instructions
• Support Software & Version
• Device Firmware and Software
• Spare Part List
Spend some time familiarizing yourself with any additional customer/site-specific tools used to track hardware failure.

Page 101
MODULE 6: Hardware Validation & RMA
AHS

Return Merchandise Authorization

The Return Merchandise Authorization (RMA) process will vary, depending on the region, RMA location and contract with the client.
The general procedure is described below, however, your mentor will explain any region/client/site-specific procedures to you.
Record your site-specific procedures in the space provided at the end of this section.
Generally, AHS Customers pay a fee for a Repair and Maintenance Plan (RAMP), or a Maintenance and Repair Contract (MARC). This
means that all parts are covered for any failure if a RAMP or MARC fee is being paid. Note that intentional or operational damage to
parts is excluded from contracts, and in this instance, replacement is charged back to the client.
Additionally, a warranty is applied, regardless of whether a RAMP or MARC exists. The warranty period for all Komatsu AHS parts is 1
year from the date the part was installed, or 18 months from the date of shipment of the part from the dealer location, whichever
occurs first.

General RMA Procedure

The procedure starts when a part is deemed faulty, and this status was confirmed by a Tier 1 engineer who documented the failure.
The faulty part will be replaced with a spare part, to maintain operations, and:

1. An RMA ticket is created by the Tier 1 engineer. The RMA ticket:

• Should reference the original Zendesk ticket.
• Should include a Hardware Fault Form detailing the repair, serial numbers ON and OFF, and any supporting
documentation.
• May be created for individual components or for a shipment of components, depending on site/location conventions.
Your mentor will explain any site-specific conventions. Record this information in the space provided.
2. The RMA department in Tucson will provide the paperwork required for customs and shipping:
• The origin documentation will list the country of origin of the part and its value.
• This is then used by the Tier 1 engineer to fill out the customs form CBP3311.
The customs and shipping paperwork is obviously region/country specific. Your mentor will explain any region-specific
procedures and paperwork. Record this information in the space provided.
3. The Tier 1 engineer typically prepares and performs the shipping:
• A commercial invoice/packing list should list all components and the box # they are packed in, (if there is more than
one box in the shipment).
• All of the documents created up to this point are put in a Document Package, and a package included in every box in
the shipment. A package is also affixed to the exterior of every box, containing three copies of each document. This
may seem excessive; however, three copies are required: one copy for customs, one for the shipper, and one for the
broker. (To reiterate: One copy of each document is placed in a document packet inside the box and three copies of
each document is placed in a package and attached to the outside of the box.)
• Full details of the shipper and destination address should be on the outside of each box.
• If there is more than one box in the shipment, boxes should be numbered and state the total number of boxes. (Box 1
of 3, or box 2 of 2, for example.)
• The shipping company documentation.
• Client Work Order form, or similar, depending on the site Service Level Agreement (SLA).
Note that in addition to the Client Work Order form, there may be other client/site-specific differences, such as specific shipping
instructions / options, and pick up /drop off locations. Your mentor will explain any client-specific procedures. Record this
information in the space provided.

Page 102
MODULE 6: Hardware Validation & RMA
AHS

4. The RMA department will repair or replace the part, depending on the part, the failure, or the complexity of the issue. For
example, due to the fabrication process, Emergency Stop Button Assemblies are not repaired, and will be replaced.
5. The RMA department ships the parts back to site. Note: Ensuring that all paperwork is correct on initial shipment, will result in
minimal turnaround/shipping return time.
6. Parts are received by the Tier 1 engineer and added to the site inventory.

Notes

For warranty items (consumables and non-consumables), the process is the same. However, the wording on the RMA ticket for a
warranty item needs to be explicit in the ticket title for tracking purposes. (Typically, the word Warranty is included in the title along
with the part number / serial number at the very least.)
Damaged items can be sold by the site inventory manager or through the corporate sales group based in Tucson. This will depend on
inventory levels, the SLA, and lead times, amongst other factors.

Site Specific Procedures

………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………

Page 103
MODULE 6: Hardware Validation & RMA
AHS
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………

Tasks

Spend some time familiarizing yourself with:

• The RMA client contract for your site and client-specific procedures.
• Examples of RMA tickets and RMA tickets for warranty parts.

Page 104
MODULE 6: Hardware Validation & RMA
AHS

Spares
Faulty parts are replaced with spares to ensure operations continue; therefore, an inventory of spares must be readily available
onsite. There are two rules for AHS spare part inventory management:
• Base the inventory on turnover: The value of the parts in spares is a set percentage of the total site annual turnover. (Your
mentor can provide this figure. Record this information in the space provided below). This rule is used on more established
sites, where a pattern of regularly failing parts exists. This will also vary from site to site due to different operating
environments.
• 10% of the installed fleet for consumables and non-consumables: 10% of the total number of parts installed on the whole
truck fleet must be available in spares at any given time.

Site Specific Procedures

………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………………………………………………………………………………

Part Numbers

To save time, and to ensure that the correct part is replaced, you must always quote the part number. This can be found in the part
specific installation guides, under the Miscellaneous Drawings and Work Instructions section on the hardware item page, reached via
the AHS HW Family page.
System drawings, also found in the Miscellaneous Drawings and Work Instructions section, are useful, however, they only show part
numbers for high-level parts, and do not generally include part numbers for required cabling, connectors, or fasteners, for example.

Tasks

Spend some time familiarizing yourself with:

• Your site-specific spare parts inventory management procedure.
• The location of hardware part numbers in the Miscellaneous Drawings and Work Instructions documents.

Page 105
 AHS

Page 106