Software Requirements Specification

Haul Truck Optimization plan

Prepared for Black Lung Mining Co.

Prepared by Path-e-tech Inc.

April 1, 2014
Table of Contents
Table of UI Models .................................................................................................................................................... 3
Revision History ........................................................................................................................................................ 4
Changes Made Based on Client Requests.................................................................................................................. 4
Forward Traceability Table ....................................................................................................................................... 5
1 Introduction .......................................................................................................................................................... 7
1.1 Purpose .......................................................................................................................................................... 7
1.2 Project Scope.................................................................................................................................................. 7
1.3 Glossary of Terms ........................................................................................................................................... 7
1.4 Data Dictionary ............................................................................................................................................... 8
1.5 References ..................................................................................................................................................... 9
1.6 Overview ........................................................................................................................................................ 9
2 Overall Description ................................................................................................................................................ 9
2.1 Product Perspective........................................................................................................................................ 9
2.2 Product Features .......................................................................................................................................... 10
2.3 User Classes and Characteristics ................................................................................................................... 10
2.4 Operating Environment ................................................................................................................................ 11
2.5 Design and Implementation Constraints ....................................................................................................... 11
2.6 Assumptions and dependencies ................................................................................................................... 11
3 System Features .................................................................................................................................................. 11
3.1 Pit Dispatch Display ...................................................................................................................................... 11
3.1.1 Description and Priority ......................................................................................................................... 11
3.1.2 Stimulus/Response Sequences .............................................................................................................. 12
3.1.3 Functional Requirements ...................................................................................................................... 12
3.2 In-truck Display............................................................................................................................................. 13
3.2.1 Description and Priority ......................................................................................................................... 13
3.2.2 Stimulus/Response Sequences .............................................................................................................. 13
3.2.3 Functional Requirements ...................................................................................................................... 13
3.3 Backend Data Storage................................................................................................................................... 13
3.3.1 Description and Priority ......................................................................................................................... 13
3.3.2 Stimulus/Response Sequences .............................................................................................................. 14
3.3.3 Functional Requirements ...................................................................................................................... 14
3.4 Maintenance Tracking .................................................................................................................................. 14
3.4.1 Description and Priority ......................................................................................................................... 14
3.4.2 Stimulus/Response Sequences .............................................................................................................. 14
3.4.3 Functional Requirements ...................................................................................................................... 14
4 External Interface Requirements ......................................................................................................................... 14
4.1 User Interfaces ............................................................................................................................................. 14
4.2 Hardware Interfaces ..................................................................................................................................... 15
4.3 Software Interfaces ...................................................................................................................................... 15
4.4 Communications Interfaces .......................................................................................................................... 15
5 Other Non-Functional Requirements ................................................................................................................... 15
5.1 Performance Requirements .......................................................................................................................... 15
5.2 Safety Requirements .................................................................................................................................... 15
5.3 Security Requirements ................................................................................................................................. 16
5.4 Software Quality Attributes .......................................................................................................................... 16
6 Other Requirements ............................................................................................................................................ 16
7 Use Cases ............................................................................................................................................................ 16

2
 7.1 List of Use Cases ........................................................................................................................................... 16
7.2 Use Case Diagram ......................................................................................................................................... 17
7.3 Use Cases ..................................................................................................................................................... 18
Use Case 1 - User logs in to the system .......................................................................................................... 18
Use Case 2 - Select an entity by location ........................................................................................................ 19
Use Case 3 - Select an entity by ID .................................................................................................................. 20
Use Case 4 – Pit Dispatcher or Foreman views KPIs ........................................................................................ 21
Use Case 5 – Pit Dispatcher or Foreman view truck information .................................................................... 21
Use Case 6 – Pit Dispatcher reroutes a truck .................................................................................................. 22
Use Case 7 – Pit Dispatcher marks a problem zone on a map ......................................................................... 23
Use Case 8 – Pit Dispatcher deletes a problem zone ...................................................................................... 23
Use Case 9 – Truck driver views updated route information........................................................................... 24
Use Case 10 – Truck driver views problem zone notification .......................................................................... 25
Use Case 11 – Add a maintenance record ...................................................................................................... 25
Use Case 12 – View truck repair history ......................................................................................................... 26
8 Models ................................................................................................................................................................ 27
8.1 Domain Models ............................................................................................................................................ 28
The ER diagram in............................................................................................................................................... 28
8.2 UI Models ..................................................................................................................................................... 30
8.2.1 Login Screens ........................................................................................................................................ 30
8.2.2 Pit Dispatch Screens .............................................................................................................................. 32
8.2.3 Foreman Screens ................................................................................................................................... 34
8.2.4 Truck Driver UI ...................................................................................................................................... 34
8.2.5 Mechanic Screens.................................................................................................................................. 36
Appendix A: Removed Features .............................................................................................................................. 38
Appendix B: Elicitation Transcript ........................................................................................................................... 39

Table of UI Models
UI Model 1: Truck Driver Login ............................................................................................................................... 30
UI Model 2: Mechanic Login ................................................................................................................................... 30
UI Model 3: Pit Dispatcher Login ............................................................................................................................. 31
UI Model 4: Pit dispatcher main screen .................................................................................................................. 32
UI Model 5: Pit Dispatcher screen with problem area selected ............................................................................... 32
UI Model 6: Pit dispatcher screen confirming deletion of a problem area ............................................................... 33
UI Model 7: Pit dispatcher UI with Truck driver selected......................................................................................... 33
UI Model 8: Foreman Main Screen ......................................................................................................................... 34
UI Model 9: foreman screen with Truck Selected .................................................................................................... 34
UI Model 10: Truck Driver UI .................................................................................................................................. 35
UI Model 11: Truck Driver UI alerting driver of new routing information ................................................................ 35
UI Model 12: Truck Driver UI displaying a problem zone ......................................................................................... 36
UI Model 13: Mechanic Add new record screen ..................................................................................................... 36
UI Model 14: Mechanic main screen - search records ............................................................................................. 37
UI Model 15: Mechanic error adding new record screen ........................................................................................ 37

3
Revision History
Name Date Reason for Changes Version
Path-e-Tech February 9, Initial writing 1.0
Inc. 2014
Black Lung February 18, Annotations on original document. 1.1
Mining Co. 2014
Path-e-Tech March 12, Changes from client comments (noted below) and additional 2.0
Inc. 2014 details regarding the application model
Path-e-Tech March 13, Fixed spelling and grammar issues in document. 2.01
Inc. 2014
Path-e-Tech April 1, 2014 Includes priorities for use cases and mappings from UI 3.0
models to use cases to functional requirements

Changes Made in Revision

Change Made Context Client comment/Reason
for change
Forward traceability table added Request by stakeholder.
Users will no longer be able to turn map Previously Requirement 4.1.5 Negotiations.
layers on and off.
Requirements added to Pit Dispatch Section 3.1 Requirements were
Display system feature absent.
Additional requirements added to Section 3.4 Requirements were
mechanic’s interface (maintenance absent.
tracking interface)
Requirements in Section 4.1 moved to Previously requirements 4.1.3 Moved to section 3.1
section 3.4 through 4.1.5 under pit
dispatcher view
Formatting of use cases modified Section 7.3 Stakeholder request

4
Forward Traceability Table
Functional Requirement Use Case UI Model
Req-3.1.3.1: Locations, speed of Use Case 4 – Pit UI Model 4: Pit dispatcher main screen
trucks, tire pressure, and load Dispatcher or Foreman UI Model 8: Foreman Main Screen
weight shall be polled and updated views KPIs
on the pit dispatcher’s display
every second when network
connectivity allows. (Elicitation 1)
Req-3.1.3.2: Route changes made Use Case 6 – Pit UI Model 7: Pit dispatcher UI with Truck driver
by pit dispatch will be pushed to a Dispatcher reroutes a selected
driver’s in-truck display within 1 truck UI Model 9: foreman screen with Truck Selected
second when network connectivity Use Case 9 – Truck driver UI Model 10: Truck Driver UI
allows. (Elicitation 1) views updated route UI Model 11: Truck Driver UI alerting driver of
information new routing information
Req-3.1.3.3: Users will be able to Use Case 2 - Select an UI Model 4: Pit dispatcher main screen
search for trucks both by ID and by entity by location UI Model 8: Foreman Main Screen
location. Use Case 3 - Select an UI Model 7: Pit dispatcher UI with Truck driver
entity by ID selected
UI Model 9: foreman screen with Truck Selected
Req-3.1.3.4: Users will be able to Use Case 4 – Pit UI Model 4: Pit dispatcher main screen
view detailed information on Dispatcher or Foreman UI Model 8: Foreman Main Screen
individual trucks. views KPIs UI Model 7: Pit dispatcher UI with Truck driver
Use Case 5 – Pit selected
Dispatcher or Foreman UI Model 9: foreman screen with Truck Selected
view truck information
Req-3.1.3.5: Pit Dispatchers will be Use Case 7 – Pit UI Model 4: Pit dispatcher main screen
able to mark areas as problem Dispatcher marks a
zones. problem zone on a map
Req-3.1.3.6: Pit Dispatchers will be Use Case 8 – Pit UI Model 4: Pit dispatcher main screen
able to remove areas marked as Dispatcher deletes a UI Model 5: Pit Dispatcher screen with problem
problem zones. problem zone area selected
UI Model 6: Pit dispatcher screen confirming
deletion of a problem area
Req-3.2.3.1: The in-truck display Use Case 10 – Truck UI Model 10: Truck Driver UI
will display a notification driver views problem UI Model 12: Truck Driver UI displaying a
immediately upon entering a zone notification problem zone
problem zone marked by pit
dispatch. (Elicitation 1)
Req-3.2.3.2: The in-truck display Use Case 10 – Truck UI Model 10: Truck Driver UI
will have a red border while in a driver views problem UI Model 12: Truck Driver UI displaying a
problem area. zone notification problem zone

Req-3.2.3.3: Any notification Use Case 10 – Truck UI Model 10: Truck Driver UI
displayed on the in-truck display driver views problem UI Model 12: Truck Driver UI displaying a
from entering a problem zone will zone notification problem zone
be removed immediately upon
leaving a problem zone. (Elicitation
1)
Req-3.2.3.4: Routing information Use Case 6 – Pit UI Model 7: Pit dispatcher UI with Truck driver
sent from pit dispatch will be Dispatcher reroutes a selected
displayed within 1 second on the truck UI Model 9: foreman screen with Truck Selected

5
in-truck display when network Use Case 9 – Truck driver UI Model 10: Truck Driver UI
connectivity allows. (Elicitation 1) views updated route UI Model 11: Truck Driver UI alerting driver of
information new routing information

Req-3.2.3.5: The in-truck display Use Case 9 – Truck driver UI Model 10: Truck Driver UI
will have a yellow flashing border views updated route UI Model 11: Truck Driver UI alerting driver of
for ten seconds when the truck’s information new routing information
route has been changed.

Req-3.3.3.1: Access to the data Use Case 1 - User logs in UI Model 1: Truck Driver Login
server will require authentication. to the system UI Model 2: Mechanic Login
(Elicitation 1) UI Model 3: Pit Dispatcher Login

Req-3.4.3.1: Mechanics will have Use Case 12 – View truck UI Model 14: Mechanic main screen - search
the ability to search for historic repair history records
service records. (Prototype
Demonstrations)
Req-3.4.3.2: Mechanics will have Use Case 11 – Add a UI Model 14: Mechanic main screen - search
the ability to add service records maintenance record records
for trucks. (Elicitation 1) UI Model 13: Mechanic Add new record screen
UI Model 15: Mechanic error adding new record
screen

Req-5.3.1: Remote web access to Use Case 1 - User logs in UI Model 1: Truck Driver Login
the system must be controlled by a to the system UI Model 2: Mechanic Login
per user login/password system. UI Model 3: Pit Dispatcher Login
(Elicitation 1)
Req-5.3.2: Only employees Use Case 1 - User logs in UI Model 1: Truck Driver Login
with login credentials are allowed to the system UI Model 2: Mechanic Login
to access the system. UI Model 3: Pit Dispatcher Login

6
1 Introduction
1.1 Purpose
This application concerns the truck drivers at Black Lung Mining Co.; the pit dispatch controllers who
issue directions, view Key Performance Indicators (KPI’s), and generally control most activity at the site;
and the mechanics who maintain the trucks. Currently, the truck drivers must use CB radios to
communicate with the pit dispatch control and keep them up to date with their location. The pit
dispatch controllers communicate new directions to the truck drivers over CB radio as well. This system
will automate this process by sending GPS tracking coordinates to the pit dispatch controller, and
allowing the pit dispatcher to send new directions to the driver’s GPS system.

Additionally, the system will keep track of the repair history for the trucks, and allow mechanics to
update it when they make repairs.

1.2 Project Scope

The haul truck optimization plan benefits Black Lung Mining Co. from different perspectives. The system
provides a modern interface for the pit dispatcher, mechanics, and truck drivers. The database stores
information such as truck location, truck speed, tire pressure, load weight, arrival and departure time
from shovel and repair history for the foremen. The system can be used to reroute trucks, identify
dangerous drivers, lower maintenance cost on trucks and improve the efficiency of the company.

1.3 Glossary of Terms

Term Definition
CB radio A device which provides short distance, two way radio communication between
individuals.
DBA A person who manages databases (Database Administrator).

GPS Satellite navigation system that provides the location of a tracer in all-weather
condition.
HTTP Hypertext Transfer Protocol - Protocol for data communication.
KPI Key performance indicator - includes things like haul cycle, average speed, etc.
Pit A Black Lung Mining Co. employee who reroutes trucks.
Dispatcher
Shovel A piece of heavy mining machinery that loads trucks with coal.
TCP Transmission Control Protocol - A protocol which is used when connecting to the World
Wide Web

7
1.4 Data Dictionary

Entity Data Data description

Driver/ Foreman/ Driver The employee of Black Lung Mining co. who drives the
Pit Dispatcher trucks. Employee uses the system to know which route he
is supposed to take
Name of Employee The name of the employee (i.e. John Doe)
(Name)
Employee Credentials The credentials (i.e. Username and password) for an
(Credentials) employee to gain access to the system
In-Truck System In-Truck System The in-trucks system, used to display assigned routes and
alerts to drivers.
Truck Tire Pressure The pressure of a truck’s tires, as read by the sensors on
the truck.
Truck Speed The speed of the truck, as read by the sensors on the
truck.
Truck Location The location of the truck, as read by the GPS on the
truck.
Truck Load Weight The load weight of the truck, as read by the sensors on
the truck.
Display The display screen used by the in truck display to show
data, such as the map, or alerts.
Route Route Path The path that pit dispatch assigns to a truck to take. The
path will go between a shovel and a dump site.
Map Site Map A map for the dig site, excluding all roads and points of
interest. Each site has its own map
Map Roads The data describing the locations of the roads on the site
maps.
Shovel Locations The data describing the locations of the shovel on the
map.
Dump Locations The data describing the locations of the dump sites on
the map.
Repair entry Truck Identification A unique identifier for the truck.
(Truck ID)
Damage Description A description of the damages done to a truck. This is
stored in the truck’s repair history
Labour Cost The labour portion of the cost of repairs done to a truck.
This is stored in the repair history.
Parts Cost The total cost of all parts used when repairing the truck.
Repair work done A description of the work done to fix a broken truck. This
is stored in the repair history.
Problem Zone Region The region of a map which has been marked as a
‘problem zone’.
Problem Zone The description of the issue being marked by the
Description problem zone.
Nature of Work A brief description of the issue being experienced by the
truck, selected from a dropdown list within the

8
 mechanic’s UI.
Entry DateTime The time and date at which a truck entered the repair
shop for repairs.
Exit DateTime The time and date at which a truck exited the shop after
being repaired.
Mechanic Mechanic name The name of the mechanic (i.e. John Smith)
Credentials The login information (i.e. username and password) for
the mechanic
Mechanic ID A unique ID used to identify mechanics.
Other KPI’s KPI Key performance indicator; used by Black Lung Mining
co. for measuring performance
Haul Cycle The total round trip time for a truck from shovel to dump
to shovel

1.5 References
[1] Black Lung Mining Co., "Haul Truck Optimization Plan Request for Proposals," 28 January 2014.
[Online]. Available: http://web.uvic.ca/~dprince/docs/rfp2.pdf.

1.6 Overview
This document provides a high-level description of the requirements for completion of the haul truck
optimization plan, as described by Black Lung Mining Co. in Appendix B, and [1]. The Overall Description
section below gives an overview of the functionality of the product as well as short description of users
and the system’s operating environment. The system constraints, assumptions and dependencies are
mentioned in this section as well. In the System Features section, the response sequences and
functional requirements of the system’s features are described. The external interfaces such as user
interfaces, hardware devices, software interfaces and communication devices and protocols are
described in the External Interface Requirements section. Performance, safety, security and software
quality attributes are described in the Other Non-Functional Requirements section. All remaining
requirements are specified in the Other Requirements section.

A list of removed features can be found in Appendix A, while Appendix B includes the transcript of the
requirements elicitation, which is referenced throughout the document.

2 Overall Description
2.1 Product Perspective
Black Lung Mining Co. requires an additional communication method between their pit dispatch
controllers and their truck drivers, as a supplement to their current CB radio system. Currently, Black
Lung Mining uses the CB radios to communicate information such as location and routes between their
truck drivers and pit dispatch controllers.

The replacement system will enhance communication by allowing pit dispatchers to view near real time
data about the truck driver’s location, speed, load weight and tire pressure, allowing the dispatchers to
make informed decisions about which shovels and dump sites the trucks need to be sent to. The
interface will get this information from a continuously updated database. Additionally, the system will

9
allow pit dispatchers to send truck drivers along different routes by transmitting routing data to the in
truck system.

The in-truck display is a navigational device which will be mounted in all of Black Lung Mining’s trucks.
This device will show current route data, which will be updated whenever new information is sent by pit
dispatch. The device is also responsible for transmitting data to the database for use by pit dispatch
control, and foremen.

As a separate part of this same initiative, mechanics will have access to another portion of the system,
which will allow them to record the repair history of the trucks for use by the foremen.

Lastly, all information must be sent to a database, which will be maintained by Black Lung Mining Co.
This information will be used internally for reports to keep the foremen informed about daily
operations.

2.2 Product Features

In-truck system

The in-truck system will display a route for the truck drivers to follow, as well as notifying drivers of
areas which have been marked ‘problem zones’ by pit dispatch. This component will also be the device
which transmits all of the truck’s information (location, speed, load weight, tire pressure, arrival and
departure time from shovels and dump sites) to the database.

Pit Dispatch Interface

The pit dispatch interface will allow the pit dispatch controllers to view the location, speed, load weight,
and tire pressure of all trucks connected to the system. The display will also show average load and
dump times, and departure and arrival times for shovels. Additionally, the interface will allow the
dispatcher to send a new route to the trucks, which will be displayed on the in-truck display.

Mechanic Interface

The mechanic’s interface will allow mechanics to record the repair history of trucks when they are
brought into the shop for repairs and to view previous repair records for a given truck.

Database

All data collected from the trucks and input into the system by mechanics will be sent to the Black Lung
Mining Co.’s database, which will be managed by their DBA, and will be accessible to the IT team.

2.3 User Classes and Characteristics

The users are employees of Black Lung Mining Co.; the pit dispatch controllers, foremen, truck drivers,
mechanics, and the DBA.

The pit dispatch controller uses the system to monitor the speed, load, and route of the trucks, and
gives them new routes accordingly. The pit dispatch controller uses the system as a supplement to the
old CB radio system they used before.

The foremen use the system to monitor the same information as the pit dispatch controller.

10
The truck drivers use the system to monitor where they are along their route, as well as to view new
routes in real time as they are received, and to be notified upon entering a problem zone.

The mechanics use the system to keep track of the repair history of the trucks, and to keep track of any
trucks with regular issues.

The DBA needs access to the raw data held in the database in order to create reports for the foremen.
As a database expert, no views or interface needs to be created.

2.4 Operating Environment

In-truck system

The in-truck system operates under harsh conditions. The inside of the truck is ‘super loud’, ‘dirty’, and
‘cold’, with ‘coal everywhere’. The vehicle’s suspension causes the cabin to be in constant motion, often
deviating 3-4 feet vertically. Therefore, the in-truck devices must be mounted securely.

Mechanic system

The mechanic system must be usable from the desktop computers within the machine shops.

Pit dispatch controller

The pit dispatch system must be usable by the pit dispatchers and foreman (in read only mode). It must
be accessible and function on a number of devices, including Windows, and common mobile browsers
(chrome and safari on phones and tablets).

2.5 Design and Implementation Constraints

Server components must run on the hardware owned by Black Lung Mining Co. Database components
and must be using an SQL-compatible language, as Black Lung Mining Co.’s DBA is responsible for
managing and maintaining it.

2.6 Assumptions and dependencies

The system depends on third party requirements. A third party will be providing the hardware for
monitoring the truck’s load, tire pressure, current speed, and location, and will be transmitting this data
to our in-truck system.

The system will also be dependent on utilizing either the existing networks (provided by Black Lung
Mining Co.) or a satellite system for communication.

3 System Features
The proposed solution application system, classified under the Michael Jackson classification system, is a
control system as it is used to control the routes that the trucks of Black Lung Mining Co. take.

3.1 Pit Dispatch Display

3.1.1 Description and Priority
A display for pit dispatch controllers which will show information about the trucks and drivers on the
mine. This display will also allow pit dispatch to assign a route for a truck to take. Finally, pit dispatch

11
will be able to mark problem zones, so that when trucks drive through them they will receive a
notification in their in-truck display. This feature is high priority.

3.1.2 Stimulus/Response Sequences

View Map  Pit dispatch will be able to view the map

 Pit dispatch will be able to pan and zoom the map

 Pit dispatch will be able to turn map layers on and off

View truck  Pit dispatch will select a truck whose information they wish to view from a
information list of trucks.

 The system will display an overlay showing the trucks driver, weight, current
speed, historic arrival and departure times from shovels, haul cycle, and
currently assigned route.

Assign a route  Pit dispatch will view the truck overlay as in “View truck information”
for a truck
 Pit dispatch will select a “Change Route” button on the overlay

 Pit dispatch will select and drag points on the current route, each time the
system will automatically recalculate an optimal route using the desired
points

 Pit dispatch will select a “Save Route” button and the new route will be
pushed to the drivers in-truck display.

Mark a problem  Pit dispatch will select a “Mark a Problem Zone” button then clicks and drags
zone to select an area on the map.

 The system will display a box prompting for a description of the problem

 When a driver drives through a problem zone a notification will be displayed

on their in-truck display, and the border of the display will flash red for 10
seconds, and then turn solid red

3.1.3 Functional Requirements

Req-3.1.3.1: Locations, speed of trucks, tire pressure, and load weight shall be polled and updated on
the pit dispatcher’s display every second when network connectivity allows. (Elicitation 1)

Req-3.1.3.2: Route changes made by pit dispatch will be pushed to a driver’s in-truck display within 1
second when network connectivity allows. (Elicitation 1)

Req-3.1.3.3: Pit Dispatchers will be able to search for trucks both by ID and by location.

Req-3.1.3.4: Pit Dispatchers will be able to view detailed information on individual trucks.

Req-3.1.3.5: Pit Dispatchers will be able to mark areas as problem zones.

12
Req-3.1.3.6: Pit Dispatchers will be able to remove areas marked as problem zones.

3.2 In-truck Display

3.2.1 Description and Priority
A display for truck drivers which will show their current location and the route assigned to them by pit
dispatch. This feature is high priority.

3.2.2 Stimulus/Response Sequences

View route  Truck drivers will be able to see their current location and detailed route
information information, including directions about their currently assigned route on a
map-style interface.

Alert driver to  Alert will display on display displaying a message defined by the pit
problem areas dispatch for the entire time the driver is in a problem area.

 Edges of screen will turn red for the entire time the driver is in the
problem area.

Alert driver to  When the route of a truck has been changed, a yellow border on the map
route change will flash, alerting the driver to the change.

3.2.3 Functional Requirements

Req-3.2.3.1: The in-truck display will display a notification immediately upon entering a problem zone
marked by pit dispatch. (Elicitation 1)

Req-3.2.3.2: Upon entering a problem zone, the in-truck display’s border will flash red for ten seconds,
then will remain red until the truck leaves the problem zone.

Req-3.2.3.3: Any notification displayed on the in-truck display from entering a problem zone will be
removed immediately upon leaving a problem zone. (Elicitation 1)

Req-3.2.3.4: Routing information sent from pit dispatch will be displayed within 1 second on the in-truck
display when network connectivity allows. (Elicitation 1)

Req-3.2.3.5: The in-truck display’s border will flash yellow for ten seconds when the truck’s route has
been changed.

3.3 Backend Data Storage

3.3.1 Description and Priority
The following data will be collected from the truck and stored in a data server for Black Lung Mining
Co.’s IT department:

 Arrival and departure times at shovels and dump sites for each truck
 Average speed per truck per haul cycle
 Load weight per haul cycle
 Wait and load time per shovel per haul cycle

13
 Wait and load time at shovel per haul cycle per truck
 Repair history per truck
 Average haul cycle time
 tire pressure

This feature is a high priority.

3.3.2 Stimulus/Response Sequences

This data will be collected and recorded by the system automatically.

3.3.3 Functional Requirements

Req-3.3.3.1: Access to the data server will require authentication. (Elicitation 1)

3.4 Maintenance Tracking

3.4.1 Description and Priority
Details of repairs that are made to trucks will be recorded by the mechanic using a web interface. The
data recorded will include: the truck the repairs were made to, the repairs made, cost of labor, and cost
of parts, truck downtime, and a list of parts used for the repairs. This feature is medium priority.

3.4.2 Stimulus/Response Sequences

Recording repairs  The mechanic will open the web interface and enter the trucks id, the
made to a truck repairs made to the truck, cost of labor, cost of parts, truck downtime,
and a list of parts used for repairs.

 The mechanic submits the form and the system will record it in the
backend data server

View repairs made  The mechanic will open the web interface and enter the truck id into the
to a truck search bar.
 The mechanic submits the form and the system displays repairs made to
the selected truck.

3.4.3 Functional Requirements

Req-3.4.3.1: Mechanics will have the ability to search for historic service records. (Prototype
Demonstrations)

Req-3.4.3.2: Mechanics will have the ability to add service records for trucks. (Elicitation 1)

4 External Interface Requirements

4.1 User Interfaces
Pit Dispatcher and Forman Views

Req-4.1.1: Pit dispatchers will have access to information about all trucks. (Elicitation 2)

Req-4.1.2: The pit dispatch interface will be available to foremen, but in read only format.

In-Truck System

14
Req-4.1.3: The driver interface does not require input on the touch screen while driving. (Elicitation 1)

Req-4.1.4: The truck driver will not have access of data of other trucks. [1]

Req-4.1.5: The display will show the route given to it by the pit dispatch controller. [1]

4.2 Hardware Interfaces

Req-4.2.1: The driver interface will be displayed in a touch-screen display in the trucks. (Elicitation 1)

Req-4.2.2: The system will collect data from the tire pressure sensor and load weight sensor currently
installed in trucks. (Elicitation 1)

Req-4.2.3: With the exception of logging in, the interface will be non-interactive.

4.3 Software Interfaces

Req-4.3.1: The pit dispatch control web interface will support the google chrome web browser on
windows, and chrome and safari on mobile devices. (Elicitation 1)

Req-4.3.2: The system will use a SQL server database.

4.4 Communications Interfaces

Req-4.4.1: The location of trucks will be tracked by GPS. ([1] and Elicitation 1)

Req-4.4.2: HTTP will be used as a protocol sending the web pages used by mechanics and the pit
dispatch controllers.

Req-4.4.3: TCP will be used as a protocol for communicating between trucks and office.

Req-4.4.4: Satellite Internet will be used for communication between trucks and server software.

5 Other Non-Functional Requirements

5.1 Performance Requirements
Pit Dispatch View

Req-5.1.1: Tire pressure needs to be measured intermittently, being updated at least every ten
minutes. (Elicitation 1)

Req-5.1.2: Speed, load weight, and location data must be near-real time, and should be updated every
second when connectivity permits it. (Elicitation 1)

Req-5.1.3: Arrival and departure time from shovels should be updated within 5 seconds. (Elicitation
1)

In-Truck Display

Req-5.1.4: Route information must be updated as soon as possible once sent from pit dispatch.
Update time must be less than one second when connectivity permits it. [1]

5.2 Safety Requirements

In-Truck Display

15
Req-5.2.1: The route displayed must be entirely along a completed road (i.e. the route shown must
not take the vehicle off-road) (Elicitation 1)

Req-5.2.2: The in-truck display must be securely mounted to prevent it from becoming detached
during operation. (Elicitation 1)

Req-5.2.3: The only time the driver interacts with the touchscreen is when they login.

5.3 Security Requirements

Req-5.3.1: Remote web access to the system must be controlled by a per user login/password
system. (Elicitation 1)

Req-5.3.2: Only employees with login credentials are allowed to access the system.

Req-5.3.3: The DBA at Black Lung Mining Co. must be able to manage the user’s logins and
passwords.

Req-5.3.4: Only users specified as a ‘Pit Dispatch Controller’ are allowed to change the routes of
trucks. (Elicitation 1)

Req-5.3.5: Only users specified as a ‘Truck mechanic’ are allowed to add repair history of a truck.

5.4 Software Quality Attributes

Req-5.4.1: All data stored in the database must be accessible by the DBA. By this, it is meant that
the DBA must be able to view and modify all of the raw data stored by the system, no explicit views or
interfaces will be provided. (Elicitation 1)

Req-5.4.2: The system must be extensible by allowing other software applications or components
to have access to the database. (Elicitation 1)

Req-5.4.3: The system must maintain 99% uptime for all non-database server side components.
Downtime is considered any inaccessibility to the system while the database is online, the Black Lung
Mining intranet is running, and the server and client machines have access to the internet.

6 Other Requirements
Req-6.1: All system components will be in English. No other language support will be provided.
(Elicitation 2)

Req-6.2: Current logbook data will be imported into the system either manually, or automatically.
(Elicitation 1)

7 Use Cases
Use Cases describe the interaction between users and the system. Each use case describes the
interactions required by the user in order to complete a specific goal or task. The use cases defined this
section describe all tasks that can be completed through the system.

7.1 List of Use Cases

16
The following is a complete and exhaustive list of tasks which can be completed through the system:

1. Pit Dispatcher or Foreman views KPIs

2. Pit Dispatcher or Foreman view truck information
3. Pit Dispatcher reroutes a truck
4. Pit Dispatcher marks a problem zone on a map
5. Pit Dispatcher deletes a problem zone
6. Truck driver views updated route information
7. Truck driver is notified of entering a problem zone
8. Mechanic adds a repair/maintenance record into the system
9. Mechanic views the repair history of a truck
7.2 Use Case Diagram
Figure 1 below shows an overall diagram of the interaction of the various users in the system, with
regards to the use cases that affect them.

17
 Figure 1: Use Case Diagram

7.3 Use Cases

All related screens for use cases can be found in Section 8.2 UI Models.

Use Case 1 - User logs in to the system

Use Case name:

18
Login to system.
Priority:
Must have
Description
This use case describes how a Pit Dispatcher, Foreman, Truck Driver, or Mechanic logs into the system.
Actors
Pit Dispatcher, Foreman, Mechanic, Truck Driver
Related Screens:
UI Model 1: Truck Driver Login, UI Model 2: Mechanic Login, UI Model 3: Pit Dispatcher Login
Pre-Conditions
User has an account in the database with a username and password.
Main flow
1. The user enters username in the login text field on the login screen. The system displays the login in
the text field. <UI Model 1: Truck Driver Login, UI Model 2: Mechanic Login, UI Model 3: Pit
Dispatcher Login>
2. The user enters password in the login text field on the login screen. The system displays the
password as * symbols.
3. The user clicks on the login button.
4. <Log In>The user is logged into the system, and presents the user with the home screen of the
application they are logging into
Post-Conditions
The user is logged into the system.
Alternative flows
At <Log In>, if the user enters the incorrect username/password combination, the password box is
cleared, and a message saying ‘Incorrect username or password.’ appears in red above the username
box.

Use Case 2 - Select an entity by location

Use Case name:
Select map entities by location.
Priority:
Must have
Description
This use case describes how a Pit Dispatcher selects an entity by location.
Actors
Pit Dispatcher, Foreman
Related Screens:
UI Model 4: Pit dispatcher main screen, UI Model 8: Foreman Main Screen, UI Model 7: Pit dispatcher UI
with Truck driver selected, UI Model 9: foreman screen with Truck Selected
Pre-Conditions
User must have an account in the database with a username and password. There is at least one entity
active in the mine.
Main flow

19
1. Include <Use case - User login into system > .
2. The pit dispatcher/foreman clicks on the ‘identify’ button. <UI Model 4: Pit dispatcher main screen,
UI Model 8: Foreman Main Screen>
3. The pit dispatcher/foreman selects an area or a point on the map using their mouse.
4. The result list opens to show the results from the identify.
5. The pit dispatch/foreman clicks on the correct result from the list.
6. The system displays more detailed information about the entity. <UI Model 7: Pit dispatcher UI with
Truck driver selected, UI Model 9: foreman screen with Truck Selected>
7. The use case ends.
Post-Conditions
An entity is selected, and detailed information is displayed about the entity.
Alternative flows
N/A

Use Case 3 - Select an entity by ID

Use Case name:
Select entities by ID.
Priority:
Must have
Description
This use case describes how a Pit Dispatcher selects an entity by ID.
Actors
Pit Dispatcher, Foreman
Related Screens:
UI Model 4: Pit dispatcher main screen, UI Model 8: Foreman Main Screen
Pre-Conditions
User must have an account in the database with a username and password. There is at least one entity
active in the mine.
Main flow
1. Include <Use case - User login into system >
2. The pit dispatcher/foreman clicks in the search bar. <UI Model 4: Pit dispatcher main screen, UI
Model 8: Foreman Main Screen>
3. The pit dispatcher/foreman types the id of the entity they’re searching for into the search bar.
4. The result list opens to show the results from the search.
5. The pit dispatch/foreman clicks on the correct result from the list.
6. The system displays more detailed information about the entity.
7. The use case ends.
Post-Conditions
An entity is selected, and detailed information is displayed about the entity.

Alternative flows
N/A

20
Use Case 4 – Pit Dispatcher or Foreman views KPIs
Use Case name:
View KPI’s.
Priority:
Must have
Description
This use case describes how a pit dispatcher/foreman views KPI’s; location, speed, average haul cycle
time, load weight, and tire pressure.
Actors
Pit dispatcher, foreman
Related Screens:
UI Model 4: Pit dispatcher main screen, UI Model 8: Foreman Main Screen
Pre-Conditions
The Pit Dispatcher/Foreman must have an account in the database with a username and password.
Main flow
1. Include <Use case - User login into system >
2. The Pit Dispatcher/Foreman selects an entity from the left sidebar. <UI Model 4: Pit dispatcher
main screen, UI Model 8: Foreman Main Screen>
3. The Pit Dispatcher/Foreman clicks the button associated with the selected entity to expand it.
4. The system displays KPI’s (location, speed, average haul cycle time, load weight, and tire pressure)
associated with the selected entity.
5. The use case ends.

Post-Conditions
The Pit Dispatcher/Foreman has read the desired KPI’s.
Alternative flows
N/A

Use Case 5 – Pit Dispatcher or Foreman view truck information

Use Case name:
View information about trucks/drivers.
Priority:
Must have
Description
This use case describes how a pit dispatcher/foreman views information about trucks/drivers.
Actors
Pit dispatcher, foreman
Related Screens:
UI Model 7: Pit dispatcher UI with Truck driver selected, UI Model 9: foreman screen with Truck Selected
Pre-Conditions
The Pit Dispatcher/foreman must have an account in the database with a username and password.
There must be at least one truck active in the mine.
Main flow
1. Include <Use case - User login into system >

21
2. The pit dispatcher/foreman selects a truck from their interface. Include <Use case – Select Entity by
Location> or <Use case – Select Entity by ID>. <UI Model 7: Pit dispatcher UI with Truck driver
selected, UI Model 9: foreman screen with Truck Selected>
3. The system displays the driver ID, truck ID, driver speed, load weight, gas levels, tire pressure, and
idle time for the selected truck
4. The use case ends.
Post-Conditions
The pit dispatcher/foreman has received the detailed information about the selected truck
Alternative flows
N/A

Use Case 6 – Pit Dispatcher reroutes a truck

Use Case name:
Reroute a truck.
Priority:
Must have
Description
This use case describes how a Pit Dispatcher uses the system to reroute a truck.
Actors
Pit Dispatcher
Related Screens:
UI Model 7: Pit dispatcher UI with Truck driver selected, UI Model 9: foreman screen with Truck Selected
Pre-Conditions
The Pit Dispatcher must have an account in the database with a username and password. There must be
at least one truck active in the mine.
Main flow
1. Include <Use case - User login into system >
2. The use case begins when the pit dispatcher selects a truck from their interface. Include <Use
case – Select Entity By Location> or <Use case – Select Entity By Location>. <UI Model 7: Pit
dispatcher UI with Truck driver selected, UI Model 9: foreman screen with Truck Selected>
3. The system displays more detailed information about the selected truck
4. The pit dispatcher clicks the “Reroute truck” button
5. The system prompts the Pit Dispatcher for a new route
6. <Update Route> The pit dispatcher inputs the desired new route.
7. The system prompts the Pit dispatcher to confirm the new route.
8. <Confirm Update> The pit dispatcher clicks the “confirm new route” button
9. The system makes a log of the update in the database
10. The system applies the change and updates the routing information associated with that truck
on all appropriate displays (pit dispatch, foreman, truck driver)
11. The use case ends.
Post-Conditions
The routing information on the truck driver’s in-truck display is updated to the new route
Alternative flows

22
At <Confirm Update>, if the pit dispatcher clicks the “back” button, the system goes back to the
previous screen. Return to <Update Route>

Use Case 7 – Pit Dispatcher marks a problem zone on a map

Use Case name:
Mark a problem zone.
Priority:
Should have
Description
This use case describes how a Pit Dispatcher uses the system to mark a problem zone.
Actors
Pit Dispatcher
Related Screens:
UI Model 4: Pit dispatcher main screen
Pre-Conditions
The Pit Dispatcher must have an account in the database with a username and password.

Main flow
1. Include <Use case - User login into system >
2. The pit dispatcher click “Add Problem Area” button. <UI Model 4: Pit dispatcher main screen>
3. The pit dispatcher clicks and drags to select an area of the map.
4. The system prompts the user to enter a comment about the problem zone.
5. The pit dispatcher inputs a description of the problem with that zone and clicks “Confirm” button.
6. The system creates a record of the problem zone.
7. The use case ends.

Post-Conditions
The system has a record of the new problem zone.
Alternative flows
N/A

Use Case 8 – Pit Dispatcher deletes a problem zone

Use Case name:
Delete a problem zone.
Priority:
Should have
Description
This use case describes how a Pit Dispatcher uses the system to delete an existing problem zone.
Actors
Pit Dispatcher
Related Screens:
UI Model 4: Pit dispatcher main screen, UI Model 5: Pit Dispatcher screen with problem area selected, UI
Model 6: Pit dispatcher screen confirming deletion of a problem area

23
Pre-Conditions
The Pit Dispatcher must have an account in the database with a username and password.
Main flow
1. Include <Use case - User login into system >
2. The pit dispatcher selects an existing problem zone <Selected problem zone>. Include <Use case –
Select Entity by Location> or <Use Case – Select Entity by ID>. <UI Model 4: Pit dispatcher main
screen>
3. System shows detailed information about the selected problem zone with a “Delete” button. <UI
Model 5: Pit Dispatcher screen with problem area selected>
4. Pit dispatcher clicks the “Delete” button.
5. <Confirm deletion> The system prompts the user to confirm the deletion of problem zone. <UI
Model 6: Pit dispatcher screen confirming deletion of a problem area>
6. Pit dispatcher click “Delete” button.
7. The system deletes the record of the problem zone.
8. The use case ends.
Post-Conditions
The system deletes the record of the problem zone.
Alternative flows
A. At <Confirm deletion>, if the user click “Cancel” button, then
1. It goes back to the previous step <Selected problem zone>.

Use Case 9 – Truck driver views updated route information

Use Case name:
See updated route information.
Priority:
Must have
Description
This use case describes how a truck driver sees updated route information on in-truck display.
Actors
Truck Driver
Related Screens:
UI Model 10: Truck Driver UI, UI Model 11: Truck Driver UI alerting driver of new routing information
Pre-Conditions
The Truck driver must have an account in the database with a username and password.
Main flow
1. Include <Use case - User login into system >
2. The in-truck display receives updated routing information. <UI Model 10: Truck Driver UI>
3. Truck route changed to new route on the in-truck display and the outline of the in-truck display
flashes yellow for 10 seconds. <UI Model 11: Truck Driver UI alerting driver of new routing
information>
4. The use case ends.

Post-Conditions
The routing information on the truck driver’s in-truck display is updated to the new route

24
Alternative flows
N/A

Use Case 10 – Truck driver views problem zone notification

Use Case name:
Driver notified of problem zone.
Priority:
Should have
Description
This use case describes how a truck driver sees a notification upon entering a problem zone on in-truck
display.
Actors
Truck Driver
Related Screens:
UI Model 10: Truck Driver UI, UI Model 12: Truck Driver UI displaying a problem zone
Pre-Conditions
The Truck driver must have an account in the database with a username and password.
Main flow
1. Include <Use case - User login into system >
2. The truck enters a problem zone. <UI Model 10: Truck Driver UI>
3. The in-truck display outline flashes red for 10 seconds, and a notification containing the problem
zone description is displayed in the upper right hand corner of the in-truck display. <UI Model 12:
Truck Driver UI displaying a problem zone>
4. After the 10 seconds, the border turns solid red.
5. The truck leaves the problem zone. The notification and red outline are removed.
6. The use case ends.
Post-Conditions
N/A
Alternative flows
N/A

Use Case 11 – Add a maintenance record

Use Case name:
Add repair/maintenance record.
Priority:
Nice to have
Description
This use case describes how a mechanic can enter the details of what was done when repairing a truck,
into the system.
Actors
Mechanic
Related Screens:

25
UI Model 14: Mechanic main screen - search records, UI Model 13: Mechanic Add new record screen, UI
Model 15: Mechanic error adding new record screen
Pre-Conditions
The mechanic must have an account in the database with a username and password.
Main flow
1. Include <Use case - User login into system >
2. The user selects the ‘Add new repair record’ tab from the tabs presented at the top of the
screen. <UI Model 14: Mechanic main screen - search records>
3. The system presents the mechanic with a form containing text fields for filling in the Truck ID,
Mechanic ID, Entry Date, Exit Date, Problem description, Cost of parts, Cost of Labour, Parts used
and Nature of work done. <UI Model 13: Mechanic Add new record screen>
4. <Submit>The Mechanic fills in the truck ID, plus relevant text fields, then presses the submit
button.
5. The system adds the data to the database.
6. The use case ends.

Post-Conditions
The entry has been added to the database.
Alternative flows
A. At <Submit>, if the mechanic does not fill in a required field
1. The system presents a screen which alerts them that they failed to enter a value for the required
field. This screen contains the same form with the same fields, containing the same information
the mechanic filled in before attempting to submit, but with the missing fields outlined red and
an error message displayed next to the submit button. Return to <Submit>. <UI Model 15:
Mechanic error adding new record screen>

Use Case 12 – View truck repair history

Use Case name:
Mechanic views the repair history of a truck.
Priority:
Nice to have
Description
This use case describes how a mechanic would view the repair history of a truck.
Actors
Mechanic
Related Screens:
UI Model 14: Mechanic main screen - search records
Pre-Conditions
Mechanic must have an account in the database with a username and password.
Main flow
1. Include <Use case - User login into system >
2. The system presents the user with the page for viewing repair records (main page of the mechanics
system). <UI Model 14: Mechanic main screen - search records>

26
3. <Enter Query>. The mechanic types the information (such as the truck id, problem, or mechanic) he
is searching for into the text box, then presses search or enter to submit.
4. <Display Results>The system displays the results of the search in the ‘results’ area on the left side of
the screen, grouped based on what matched (i.e. truck id, problem or mechanic). The ‘records’ box
on the right side is left empty.
5. The mechanic clicks on the group she or he is interested in.
6. The group expands to show the mechanic the entries within the group in the results field. Entries
are sorted by date.
7. The mechanic clicks the entry she or he is interested in.
8. The system displays the detailed information of the repair record on the right side of the screen, in
the ‘records’ box.
9. The use case ends.
Post-Conditions
The results are shown on the right side of the screen.
Alternative flows
At <Display Results>, if no records are found, the system displays “No results found” in the ‘results’
area, and the ‘records’ area is left empty. Return to <Enter Query>.

8 Models
Models are used to help confirm that the understanding of the data involved, and the understanding
scope of the problem is shared between both Path-e-tech developers and the stakeholders at Black Lung
Mining co. These models are broken into two categories; Domain models, which show the data involved,
the relationship between pieces of data, and flow of data through the system; and UI models, which
show samples of how the UI will be laid out in the final product. Section

27
1.4 Data Dictionary may be helpful in understanding what different pieces of data will correspond to, as
it includes a description of every piece of data referred to within the domain models.

8.1 Domain Models

Figure 2: ER Diagram

The ER diagram in Figure 2 above shows how pieces of data relate to each other.

28
 Figure 3: DFD0

The Data Flow Diagram (DFD) in Figure 3 above shows how data enters and exits the system.

Figure 4: DFD1

The DFD in Figure 4 above shows the system in more detail, by including how data is used within the
system, and how it will be stored.

29
8.2 UI Models
8.2.1 Login Screens

UI Model 1: Truck Driver Login

UI Model 2: Mechanic Login

30
UI Model 3: Pit Dispatcher Login

UI Model 4: Foreman Login

31
8.2.2 Pit Dispatch Screens

UI Model 4: Pit dispatcher main screen

UI Model 5: Pit Dispatcher screen with problem area selected

32
UI Model 6: Pit dispatcher screen confirming deletion of a problem area

UI Model 7: Pit dispatcher UI with Truck driver selected

33
8.2.3 Foreman Screens

UI Model 8: Foreman Main Screen

UI Model 9: foreman screen with Truck Selected

8.2.4 Truck Driver UI

34
 UI Model 10: Truck Driver UI

UI Model 11: Truck Driver UI alerting driver of new routing information

35
 UI Model 12: Truck Driver UI displaying a problem zone

8.2.5 Mechanic Screens

UI Model 13: Mechanic Add new record screen

36
 UI Model 14: Mechanic main screen - search records

UI Model 15: Mechanic error adding new record screen

37
Appendix A: Removed Features
Removed Requirement Source Description
Generating reports for Foremen Elicitation The system is no longer required to generate reports
for foremen
The business improvement Elicitation The system no longer requires a BID interface
department (BID) interface
Real time data retrieval for all data Elicitation Only the trucks location and speed will be real time
from the trucks
Informing truck drivers of their RS 1.1 The system no longer has the ability to inform truck
lunch break times drivers when they should go on break.
Users will be able to turn map Negotiation The system no longer supports enabling and
layers on and off. disabling map layers.

38
Appendix B: Elicitation Transcript
Path-E-Tech: The trucks that the equipment is going to be on, how far are they driving?

Black Lung Mining - Could be up to 15-20km

What sort of connectivity do these trucks have? Do they have any connectivity built in? Or... Is it just…
you have radios

- Yeah CB radios

CB radios. Anything else?

- Currently no. Just CB.

And no GPS?

- Not right now.

OK

- Are we getting the GPS put in to the trucks?

- See I don’t understand this assignment too much but GPS would be a way to go.

OK

- So we could have it already or we could have it in a box like at HQ right now or you guys could install it.

- What I’m getting at is are they responsible for the hardware?

- That part wasn’t really….. [Clear]

OK that’s beside the point I guess

What other hardware is available on the truck and drivers? Will they always have a cell phone on
them, a tablet on them?

- No cell phone, but they have their CB radios, and then ideally, a touch screen monitor.

Right but that’s not in the trucks right now

- That would be part of their GPS

- It’s not in there yet.

You mentioned that the truck drivers are a different type of end user, because they will not be
interacting with the system? You want them only to consume information?

- Right

Do truck drivers then only receive information on the CB radios right now? Or do they talk back and
forth?

- I think what we were getting at is that they shouldn’t be interacting with a touch screen, like
information should be presented to them, but there should probably be some kind of voice

39
communication. Obviously they will communicate back and forth but they shouldn’t be driving and
like…..

- We are not getting rid of the CB radios, those would still be there

- Or it could be built into the system right?

- So from dispatch communicating with the truck drivers they can talk to each other but we don’t want
truck drivers to look at other truck drivers and look at their statistics.

- But you could just have ideally some kind of forced communication that dispatch could just say “hey I
want to talk to this person” and it just comes on like the speakers in the cab

OK. You mentioned truck driver log books and that they put tire pressures, fuel levels, and arrival
times, and all that kind of stuff on them. Do they have any other sort of information, like notes or
anything like that? Will the system have to accept some sort of free-form input from the driver? Like
notes “ran over a nail and tire pressure started to drop or…..

- No…. Did we say there was a notebook that had all that stuff in there?

A log book yeah

- Ideally no they wouldn’t be. They are just drivers so if there was a problem like a nail in a tire they
would just…

They would just see the tire pressure dropping and...

- Yeah they would CB radio saying “I got an error” and they got a thing, they would take it to the shop
and the shop would enter all of the information into the system.

Ok. What do you mean by dangerous drivers?

- Well when you are driving a haul truck you are taking 3 tonnes of coal in the back, it’s very heavy, the
truck is heavy as it is, and you are on a road that was probably built yesterday so the conditions aren’t all
that great so dangerous drivers are drivers that are going too fast. Ideally you only want to be going like
15 km/h, and obviously the truck can push way faster than that. So anyone going faster than that, you
come around a corner, you are going too fast, you can’t stop, that kind of thing.

What kind of uptime are we looking at for the system?

- 24/7/365

What is the acceptable downtime?

- Acceptable would just be… so it would be down for what just system upgrades… that kind of thing?

System updates, upgrades, that kind of thing.

- Just the minimum. Whatever the system would allow.

You mentioned that you want data every 1 second from the trucks. What’s the reasoning behind
every 1 second rather than every 10 seconds? Like do you need tire pressure information for every
second from every truck?

40
- No no no. Tire pressure…. I guess it depends on what kind of information you are getting. Like tire
pressure you don’t need every second obviously. You could poll that every 10 minutes or so.

Yeah I mean it’s not going to change drastically

- Right. But GPS data you want to know exactly where they are and every 1 second that is going to get
your speed more accurately, you know, stuff like that. It’s also going to give you exactly like when you
stop at the shovel, exactly when you leave….

- And we want to know the rate at which people are stopping and starting and maybe the rate at which
they are going at like… I was thinking like characterizing drivers based on how they drive cause we are
trying to identify people that may be a bit dangerous or….

So speed and GPS?

- Yeah and I think if you have route changes or something being sent to the drivers, that needs to
happen in real time. Stuff that is being sent to the drivers has to happen right away.

That’s understandable that it be less, you had less than 5 seconds on the document and that’s
understandable.

- So the way that I picture it is that you don’t actually… like… when the information is sent we are not
sending every piece of information every second right, so the GPS would need to be every second
because you need to know where they are, but say you leave the shovel at this time, and then you arrive
at the dump at this time, you only need those 2 times. You don’t need what’s in between. That make
sense?

So you only need the tire pressure from those 2 times?

- No sorry just the time like the time you leave the shovel and then the time you arrive at the dump.
That’s all you would need but the GPS would be for... Cause you are looking at a screen right? You are
looking at a map of the mine… I mean there’s dots right, so you could see exactly where the truck is.

Would it be acceptable for the drivers to interact with the trucks when they are stopped so they could
say “I’m here” or “I’m here”

- You could have a switch that says “loading” or something, or maybe you could attach it to the e-brake
or something instead of a user having to switch on and off and remember.

I imagine if they use a log-book already then they are used to writing stuff down at the site anyways

- Yeah I mean as much of it ideally should be automated as possible

- Yeah we are trying to get it away from human... like to automate as much stuff as we can.

Do you have a server infrastructure set up already? You must have some sort of system…

- I guess we have got repeaters for our CB

So no database administrator… nothing like that?

- Well I would assume we have something

41
- Yeah there has got to be some DB that we manually enter into it

- Maybe an excel document

- Yeah sure excel document

- yeah I guess there has got to be some old lady sitting in the building in there that goes through the log
books and installs it all or sorry not installs it but….

So you don’t really have much infrastructure. This would be pretty much a new system.

- Yeah

Do you have any data sitting around that you want to be imported into the new system? Or can we
just start fresh?

- I think to a certain point existing data should be imported cause then you could monitor trends and
everything

- yeah that would be good because then we could see the progress we have made since the switchover,
compare the two, see if we are getting our money’s worth.

Is some data more important than others? What’s the most important thing you are trying to get out
of this?

- The GPS?

Is it dangerous drivers, is it better scheduling…

- the most important I guess is the time you start moving, the time you stop moving, the load weight,
how much you are moving… I guess at the end of the day that’s the important stuff. So loads for the BI
(business improvement) so you can progress your profits. And then also… sorry they wouldn’t be for…
that would just be for logs and profits and all that. Profit margins and so you could project etc. and then
the stopping and starting would be for business improvement so that they can determine how to
improve and also target the good drivers and bad drivers.

- And we also want to know which routes would be faster, shorter, all that stuff

Are there ever more than 1 driver in the truck?

- Just one. Why?

Maybe one of them could interact with the system. It just opens up options for the interface

So what happens if a truck driver takes the wrong route?

- Essentially dispatch would notice that and there would be an alarm set

I mean could it be... could there be a crash?

- Yeah

So it’s a pretty big deal

42
- oh yeah for sure but pretty much what you are doing all day long is that you are going from A to B from
B to A from A to B etc. so if you take the wrong turn you are a fuckin idiot. Put the joint down.

Right so these questions are for the pit dispatch controller

What information do you need to see? You are looking at your computer all the time, what do you
want to see?

- It would be nice to know where the drivers are, at every point in time or at least in a reasonably good
amount of time

So you are looking at a map and there are dots on the map and they are moving

- Yeah so I can basically see where they are going, and the times they are arriving and leaving at and the
speed they are going

So maybe a summary of average trip time and average load weights and stuff like that

- Yeah and I also make the decisions based on like… I’m telling them where to go basically so it would be
nice if I could characterize them like maybe I could click somewhere and it would bring up like a profile
of a particular driver based on history or based on whatever it is that we are recording right now

- We were talking about shovel use too right?

- Yeah there are also daily par levels so you have to get this amount of coal per day right? Or shift I
should say. so we need a running par level so it will show you where we are at, how much coal we have
transported, and as a relation of how much we should have done so if we are down here and we should
be up here pit dispatch is going to reroute some drivers to maybe a shorter route so maybe they are
getting more coal per hour and all that stuff

Now why wouldn’t you just use that shorter route already?

- Well you gotta get coal from over there and you gotta get coal from over here right? even if coal is way
over there you still gotta get it so you could do this all day long and you get a whole par level but then
that’s all gone and then tomorrow you are gonna go over there and you are gonna get like a quarter of
the amount.

- So we just want to balance out the loads taken in

- the amount of coal mined per day depends on the price of coal on the market so if the price is cheap
then you are gonna have a slow day, but if the price is sky high, you are gonna fuckin… you are gonna
bring in as much as you can

- and we were saying we wanted to see if there was people waiting at a certain shovel so we could
reroute people to another shovel

- That’s another KPI that you could have is wait times, wait time at shovel, average wait time at shovel.

- and it would be nice to see how long a truck has been at any given shovel so if someone has been
loading for like 20 minutes then something has probably gone wrong.

43
So I assume the truck drivers communicate with you as well so you can have conversations with them
and you are not just pushing stuff to them

- Yeah it’s a 2-way communication

When you say you want to be able to tell the driver what route to take, what format is that? Is it just a
sentence, say “take road b, you are working at site c today” or do they require a large list of “left on
coal street, right on charred”

- Well your streets are changing every day. They actually make streets, destroy streets, it’s always
changing so you can get at the coal but before your shift you have a pre-shift meeting with the foreman.
He will put up a map and he will tell you shovel a, shovel b, shovel c, dump site

So between each shovel there is one road going there and one road going back?

- Sorry between each shovel?

Between the dump site and the shovel there is one road there, one road back so you can just say “you
are working shovel c today”?

- yeah but ideally with the truck interface they should have some kind of map that will have a
highlighted route that is like “you are going here” and if it changes it will just pop up real time on their
map

- So the old system would be what you are saying but this is what we want

You mentioned live feed video cameras

- Yeah I was going to mention that. Should we say we already have them, because if think we already do
have them? Yeah ok.

And would we collect the data then? And where is that data being stored if you have an old lady
manually entering stuff into a database?

- Video is just video like up on the screen. What do you mean?

Ok so it is not being stored or sent to the pit dispatch it’s just for the driver?

- Not for the driver at all it’s for pit dispatch. So the cameras aren’t in the trucks they are actually
mounted in the mines.

- Yeah they are static cameras kind of like security cameras

- So they just kind of go up on the screens there and pit dispatch can actually have a physical……

And does that data get stored?

- Yeah I would imagine they just store a couple days’ worth and then wipe it after a couple days

Ok questions for the foreman. What information do you need to see?

- The foreman doesn't actually need too much information from the system, I’m just there to make sure
things go smoothly. The pit dispatch handles the truck routing and stuff. in mornings if would be there

44
to make decisions like which truck goes to which shovel but in terms of optimization that’s all up to pit
dispatch

- The foreman basically wants reports. Like on paper end of shift, end of day... etc.

What do those reports look like? Like average time between dumping etc.

- Yeah sure. It’s like a performance thing like how much coal you got, what is the average speed, how
much time was wasted on this… that kind of stuff. Where can we improve?

- Probably a high level like the whole mine summary, and then a per driver, per route etc.

- As much info as the guy can. He will just sift through it. It doesn’t have to be on paper either I mean
that could be an online app as well.

-probably something where he can just say “I want this this and this” and “give me this data”

What type of device is he working on? Is it paper? Is he looking at this in the field on an iPad, phone,
desktop etc.?

- I would say it would be web based so iPad as well as desktop

But like mobile or desktop interface?

- Both. IPad and desktop

- I will be spending a lot of time in an office and I am going to be going around making daily inspections
making sure everything goes smoothly as well so if I had a way to look at it in real time while I am on the
site it would be good too.

- does it need to be a self-standing app or just accessing the same web interface through an iPad?

- Just a web interface. The same as the pit dispatch. They are going to be looking at the same thing.

Ok. Truck drivers. What do you keep in your log book?

- Umm what do I keep in my log book?

- let’s say time you got to the shovel, time you left the shovel, time you got to the dump, time you left
the dump, what truck you were driving, start and end times of your shift, safety checklist, at the
beginning of your shift you have to do a 360 of your truck…

So would that safety checklist be in our system then?

- uhh yeah well the way it works in real life is that you show up for your shift, you sign in with your card,
you do your 360, you get in the truck, start it up, that’s relayed as well so your 360 time is in there
because they are having problems with people doing hour long 360s when it should only take like 10
minutes. Every single aspect of the day is basically logged. If you stop on the side of the road and take a
piss, that’s logged as well. Just as stopped time, not like “takin piss”. Your break is logged, your lunch is
logged, you sign out for your lunch and then you sign back in after your lunch and that’s logged, so they
track that as well and can identify shitty employees that way. If they are taking 75 minutes if they are
only getting a 60 etc.

45
What information do you want from an in truck display? Just routing information or do you want your
averages as well?

- No we don’t want the drivers to see any of that information

But what about the drivers personal information?

- No, that motivates fast and reckless driving. We don’t want them to see any of the data. Just route and
I don’t know… maybe when your break is? Probably not though but ….

Sounds like we should have something built into the UI for clocking breaks like start the break timer
or stop timer

- Yeah that’s gotta be in there yeah

- And you could have some sort of timer show up to alert them when there breaks are

What’s the inside of the truck like? Do you listen to music? Is it loud? How feasible are voice
commands?

- Super loud, you can have music, the CB was wired to it so your music would cut out. Its dirty, and
shitty, coal everywhere, cold, not too comfortable.

- How much does it shake? Can you mount a device?

- yeah you can mount a device but when you are driving down the street the suspension is so soft you
are constantly moving like 3-4 feet up in the air. Yeah it is pretty crazy

How is it so soft when it’s loaded with so much coal?

- The suspension is just massive I mean there is so much weight you have to absorb that somehow

Ok business improvement department. What data do you require?

- They want to have access to everything because every day could be different. They want to target
something new so they need access to all information.

- I feel like the interface would be pretty similar to what the foreman could access, like just big
summarized reports.

- well the way the business improvement worked where it was is that they don’t actually have reports
that they look at, not like pre-generated reports but they come up with an idea, talk to IT, and then IT
makes that for them

So these people are not writing SQL queries?

- No there is an IT department to do that

So I guess the way you want the data presented would be anything they want on the day

-yeah anything they want. Ideally similar to what the foreman and pit dispatch looks at but more specific
to their needs

46
- if they have the same access as pit dispatch but maybe something on top of it that gives it a little bit
more flexibility

- Pit dispatch only needs a handful of things and that is never going to change, whereas BI will be
jumping all over the place.

Is there anything else that we should know?

- I don’t know if we put in nighttime vs daytime conditions?

- Oh we were saying something about the display in the cab to switch over when it’s nighttime to a
dimmer display because we are running 24/7.

-like a navigator in a car where it switches at night so it is not burning your eyes out

Anything else?

- do you have a list of things that we want to be tracked?

No

-why don’t we go with that so we can make it more clear as to what kind of info we want to have

-we can start listing stuff now and if either of us think of anything before…..

- start times and stop times. If you are leaving a shovel or getting to a shovel or a dump or HQ. I mean
you could use that to get speed as well

- do we want real time speed as well for the dispatch? Average speed and real time speed are very
different.

- yeah that’s another thing they actually did was they targeted trouble zones like someone said it was
slippery, they were skidding too much etc. so they wanted to minimize speed there cause it was
dangerous so that’s another thing you could to is set a GPS pointer between A and B and if someone
goes over a certain speed then you could flag them, that’s something the foreman would talk about in
the morning.

- some way of marking problem zones so if dispatch could make a note of it, and maybe that’s
something that could show up in the truck that once they hit one of those zones they get a real time
alert.

- What type of list are we talking about? Is this general information or for the truck drivers?

- Just data that the system has to take

- I guess we are getting the tire pressure and stuff

- Length of breaks

- load weight

- wait times, load times, and dump times

- Time sitting at the shovel being loaded

47
- Also repair, they track specific trucks so you can look at a truck over the course of a year and it’s
broken down 3 times. You look at another truck and it’s broken down 50 times. why? You know that
kind of thing so you wanna track repairs on trucks. If a truck keeps breaking down you want to get rid of
it

This is quite a large system. All the parts might be a little bit out of scope for this assignment. What
are the most important parts of this system?

-the pit dispatch display, truck driver display, database

If we created that system and allowed the summaries to be created afterwards as a kind of add-on?

- Even the database you can’t really show us that

But you can manually query it. In the meantime could we let the IT department manually create
reports like they have been doing and we can add on that later? Or do we need a GUI application for
that?

-no no we will handle all of the reports. All we require is the DB to be populated

Thank you very much

Elicitation 3:

Do we have to deal with the fixed camera feeds and stuff?

No. We have a system that we are happy with.

48