Work Package Description: Landshark

Doc No: LS-PRP-PRJ-02
QUT Avionics Issue: 1.0

4th year Avionics Project Page: 1 of 34
Date: 31 Mar 2011
Landshark
Work Package Description
“A QUT Avionics Project”
Prepared by Date _______________

Daniel Ginn, Landshark
Checked by Date _______________

Damian Mew, Landshark
Approved by Date _______________

Damian Mew, Student Manager 2011
Authorised for use by Date _______________

Jason Ford, Project Coordinator
QUT Avionics
Queensland University of Technology
CRCSS-EESE, GPO Box 2434
Gardens Point Campus
Brisbane, Australia, 4001.
Telephone (+61 7) 3138 2207

Facsimile (+61 7) 3138 1516
Email j2.ford@qut.edu.au
This document is Copyright 2011 by the QUT. The content of this document, except that information which is in the
public domain, is the proprietary property of the QUT and shall not be disclosed or reproduced in part or in whole
other than for the purpose for which it has been prepared without the express permission of the QUT
· Last updated by Daniel Ginn on 31 March 2011 · Filename: 57506540.docx· FileSize: 54331 bytes · Template: ·
Date: 31 Mar 2011
Revision Record
Document Description of Change Date Approved

Issue/Revision
Status
1.0 Initial Issue 31 Mar 2011 Damian Mew
Date: 31 Mar 2011
Distribution List
Name Affiliation Distribution Approved

Date
Jason Ford QUT Avionics 01 April 2011 Damian Mew
Date: 31 Mar 2011
Table of Contents
ParagraphPage No.
1 Introduction..............................................................................................................................8
1.1 Scope................................................................................................................................8
1.2 Overview..........................................................................................................................8
2 Reference Documents..............................................................................................................9
2.1 QUT Avionics Documents...............................................................................................9
2.2 Non-QUT Documents......................................................................................................9
3 Documentation Numbering Scheme......................................................................................10
4 Work Packet Descriptions (WPD).........................................................................................11

4.1 Conception (Pre-System Definition).............................................................................11
4.2 Creation (Architectural Design).....................................................................................17
4.3 Implementation..............................................................................................................23
4.4 Integration/Verification.................................................................................................29
Date: 31 Mar 2011
List of Figures
FigurePage No.
No table of figures entries found.
Date: 31 Mar 2011
List of Tables
FigurePage No.
Table 3-1 - Documentation Numbering Convention.......................................................................10
Date: 31 Mar 2011
Definitions
LS Landshark
DM Damian Mew
JL Joshua Lok
MU Mircea Ungureanu
DG Daniel Ginn
IR Infra-red
Date: 31 Mar 2011
1 Introduction
1.1 Scope
This document describes in greater detail what each of the tasks in the timeline shown in the
Project Management Plan document (RD/1) are.
1.2 Overview
Landshark is a Ground Vehicle that uses a thermal/IR sensor to detect a target. The sensor
contains a single sensing element and uses optical modulation to determine the direction to the
target. The Ground Vehicle is used to either: intercept a target moving; or dock with a static
target at an operator specified angle. Ground Vehicle guidance to the target is autonomous and
generated onboard the Ground Vehicle. System operation is done via a remote operator’s
interface.
Date: 31 Mar 2011
2 Reference Documents
2.1 QUT Avionics Documents
1 LS-PRP-PRJ-01 (Project Management Plan)
2.2 Non-QUT Documents
In the following text, RD/x identifies referenced documents, where "x" denotes the actual
document.
Date: 31 Mar 2011
3 Documentation Numbering Scheme
The LS project employs a documentation-numbering scheme with the following basic format:
<Project Name> - <Project Functional Group> - <Document Type> - <sequence number>

(<Short Document Title>)
Valid Project Name
LS Landshark
Valid Project Functional Group (3 characters)
PRP Project Planning

REQ Requirements
DES Designs
TES Testing
OPM Operator’s Manual
Valid Document Type (3 characters)
PRJ Project Management Plan

PRM Project Risk Management
HSM Health and Safety Risk Management
CUR Customer Requirements
DER Derived Requirements
TST Trade Studies
CON Conceptual Design
PRE Preliminary Design
FIN Final Design
TSC Tests Cases
TSP Test Procedures
USR User Manual
MOM Meeting of Minutes
Sequence Number (2 digit sequential number)
Table 3-1 - Documentation Numbering Convention
Date: 31 Mar 2011
4 Work Packet Descriptions (WPD)
4.1 Conception (Pre-System Definition)
5 Define Customer Requirements
AIM:
To list what the customer wants from the project.
DESCRIPTION:
This task was done by Paul (the customer), so the responsibility for this was not placed on the
team.
DATE COMMENCED: N/A
DATE COMPLETED: 10/12/2010
MEMBER RESPONSIBLE: Paul
6 Generate Derived Requirements Document
AIM:
To list limitations imposed on other subsystems or the project by sources other than the customer.
DESCRIPTION:
This Document will list requirements such as limitations imposed by one subsystem on another.
DATE COMMENCED: 10/01/2011
MEMBER RESPONSIBLE: Joshua Lok
Date: 31 Mar 2011
7 Generate Conceptual Design Document
AIM:
To show the high level view of the Landshark system.
DESCRIPTION:
This document will be a basic outline to the project, defining the different subsystems.
MEMBER RESPONSIBLE: Damian Mew
8 Generate Health and Safety Risk Management Document
AIM:
To list the potential health risks in the course of this project, and then to mitigate them
DESCRIPTION:
This document will be filled out in the QUT required format for a Health and Safety document.
Date: 31 Mar 2011
9 Generate Work Breakdown Structure Document
AIM:
To identify the tasks throughout all the stages of the project and to present a timeline for the
completion of the project.
DESCRIPTION:
This task will be completed in Microsoft Project, and will show start and finish dates for each
task, as well as who is responsible.
10 Generate High Level Test Descriptions Document
AIM:
To determine how each of the customer requirements will be tested.
DESCRIPTION:
This document will list all the test cases that are necessary to verify each customer requirement.
Each test case will list the method of the test, pass and fail cases, and a diagram if necessary.
MEMBER RESPONSIBLE: Daniel Ginn
Date: 31 Mar 2011
11 Generate Configuration Management Document
AIM:
Explain how the project will handle documentation, and how the subsystems will be run to avoid
large integration problems when that stage arrives.
DESCRIPTION:
This document will explain the processes used in this project.
12 Generate Work Package Description Document
AIM:
Gives a short description of the tasks listed in the Project Management Plan (RD/1).
DESCRIPTION:
The document lists an aim, description, start and finish date and the member responsible for each
task.
Date: 31 Mar 2011
13 Generate Project Risk Management Document
AIM:
To list possible problems in the project, and the mitigate them.
DESCRIPTION:
This document will use the same table as the health and safety document.
14 Establish Project Cost
AIM:
Determine how much money is available for the project, and how much money is required for
each subsystem
DESCRIPTION:
This will involve chasing up the relevant university staff to determine how much money is
allocated to each student, as well as determining how much limitation must be placed upon
acceptable costs of individual parts investigated in trade studies.
Date: 31 Mar 2011
15 Concept Review
AIM:
Pause and look back on what we have developed so far and make sure that we are making choices
that are requirement driven.
DESCRIPTION:
This will involve a review of each subsystem by the project manager as well as the entire team.
MEMBER RESPONSIBLE: Damian Mew, Whole team.
Date: 31 Mar 2011
15.1 Creation (Architectural Design)
16 Perform Target Vehicle Trade Study
AIM:
Investigate suitable remote control vehicles to serve as the target vehicle.
DESCRIPTION:
This document will show various options and list the benefits and drawbacks of each option.
17 Perform Ground Vehicle Trade Study
AIM:
Investigate suitable remote control vehicles as a basis for the Ground Vehicle, or propose custom
designs that meet the requirements.
DESCRIPTION:
Date: 31 Mar 2011
18 Perform Target Seeker Sensor Trade Study
AIM:
Investigate various components that are required to create the IR seeker.
DESCRIPTION:
MEMBER RESPONSIBLE: Mircea Ungureanu
19 Perform Target Seeker Supporting Electronics Trade Study
AIM:
Investigate various components that are required to help the IR seeker to perform its function.
DESCRIPTION:
Date: 31 Mar 2011
20 Perform Target Seeker Design and Operation Methodology Trade Study
AIM:
Investigate how an IR seeker works and the various options for meeting the customer and derived
requirements.
DESCRIPTION:
21 Develop Ground Vehicle Interception Logic and Methodology
AIM:
Investigate methods of bearing only interception.
DESCRIPTION:
This will be a purely research orientated task.
Date: 31 Mar 2011
22 Generate Preliminary Design Document
AIM:
Detail the proposed solution to the project
DESCRIPTION:
While this document is not a final design, it gives a good deal of detail as to what parts will be
used, and how each subsystem will proceed to meet the requirements.
MEMBER RESPONSIBLE: Whole team
23 Begin IR Source Detection Software Development
AIM:
Begin the software code required to identify the bearing to the target.
DESCRIPTION:
This code will take the raw data from the IR sensor and convert it to a bearing measurement.
Date: 31 Mar 2011
24 Begin Controls Software Development and Simulation
AIM:
Begin work on the Automation software code, in addition to creation of a simulator for the
project.
DESCRIPTION:
This code will be initially produced in MATLAB, and then later on converted to whatever
language is required by the logic board.
25 Health and Safety Approval
AIM:
Have the Health and Safety document signed off by all relevant staff.
DESCRIPTION:
This document must be signed by the project supervisor, and the health and safety officer, as well
as his superior. No work can be commenced until this document has been approved.
Date: 31 Mar 2011
26 Preliminary Design Review
AIM:
To stop and look back on how we have progressed in the project and whether this is the right
direction.
DESCRIPTION:
The proposed Preliminary Design must be reviewed by the Project Manager and the whole team.
MEMBER RESPONSIBLE: Damian Mew, Whole team
27 Begin Purchasing of Subsystem Components
AIM:
Confirm purchases and order them and have the cost reimbursed.
DESCRIPTION:
To purchase an item with university funds, the item must be approved by Jason Ford, then the
item is purchased with our own money, and then a reimbursement is obtained from the QUT staff.
MEMBER RESPONSIBLE: Whole team
Date: 31 Mar 2011
27.1 Implementation
28 Prepare Target Vehicle Modification Drawings
AIM:
Recording of changes made to the Target Vehicle.
DESCRIPTION:
The customer has stipulated that a drawing of the system is better than a description, where
appropriate, therefore the modifications required to the Target Vehicle will be done up in a CAD
program.
MEMBER RESPONSIBLE: Joshua Lok, Daniel Ginn
29 Prepare Ground Vehicle Modification Drawings
AIM:
Recording the detailed construction and modification details made to the Ground Vehicle.
DESCRIPTION:
These detailed CAD drawings are always necessary for easy understanding of an object, and is
common industry practice.
MEMBER RESPONSIBLE: Damian Mew, Daniel Ginn
Date: 31 Mar 2011
30 Prepare IR Seeker Assembly Drawings
AIM:
Recording the design of the IR seeker, a point of great interest for the customer and supervisor of
the project.
DESCRIPTION:
MEMBER RESPONSIBLE: Mircea Ungureanu, Daniel Ginn
31 Prepare IR Seeker Assembly Drawings
AIM:
Recording the design of the IR seeker, a point of great interest for the customer and supervisor of
the project.
DESCRIPTION:
Date: 31 Mar 2011
32 Prepare Sonar Sensor Assembly Drawings
AIM:
Recording the design of the sonar assembly. Although of limited interest, this will show the sonar
system in its own subsystem.
DESCRIPTION:
MEMBER RESPONSIBLE: Joshua Lok, Daniel Ginn
33 Assemble/Modify Target Vehicle
AIM:
The modification of the target vehicle to the stage that full testing can be carried out with it.
DESCRIPTION:
All modifications outlined in the CAD drawings relating to this vehicle will be implemented.
Date: 31 Mar 2011
34 Assemble/Modify Ground Vehicle
AIM:
The construction of the Ground Vehicle in accordance with the proposed CAD drawings.
DESCRIPTION:
The Ground Vehicle will be constructed here so that it is ready to begin testing. As it is common
that things rarely go according to plan, whatever changes that are made to the Ground Vehicle
should be reflected in the CAD drawings as well.
35 Assemble/Modify Target Seeker
AIM:
Construct IR seeker.
DESCRIPTION:
This section of the project involves producing a finalised version of the IR system.
MEMBER RESPONSIBLE: Damian Mew, Mircea Ungureanu
Date: 31 Mar 2011
36 Install Sonar Sensor To Ground Vehicle
AIM:
Simple installation of Sonar Seeker to Ground Vehicle
DESCRIPTION:
Since this item is purchased off the shelf, little bench testing will be required, so it can be install
very early.
MEMBER RESPONSIBLE: Damian Mew, Joshua Lok
37 Prepare Environmental Control Equipment
AIM:
To prepare the testing area for testing.
DESCRIPTION:
This task prepares all the necessary equipment to perform the tests in the High Level Test
Descriptions.
Date: 31 Mar 2011
38 Prepare Safety and Protective Equipment
AIM:
To ensure the safety of all in the vicinity of the project.
DESCRIPTION:
This is extremely important, to avoid injury to persons or equipment.
39 Dry Run Testing of Subsystem’s Functionality
AIM:
Bench testing of components, to make sure they work to specifications.
DESCRIPTION:
This is the first true testing of the subsystems, to see if they actually do work, and what needs to
be done to make them work to specifications.
MEMBER RESPONSIBLE: Whole Team
Date: 31 Mar 2011
39.1 Integration/Verification
40 Integrate All Subsystems Into One
AIM:
To make one whole system
DESCRIPTION:
This combining of subsystems which should all be individually working and within specifications,
will cause new problems and complexities, which must be overcome.
41 Update High Level Test Descriptions
AIM:
With the Tests now imminent, the detailed descriptions of how each test will be run must be
recorded.
DESCRIPTION:
This step leads the way to commencement of testing.
Date: 31 Mar 2011
42 Test LS System Against High Level Test Descriptions
AIM:
To compare the system with the full requirements of the project
DESCRIPTION:
These tests will show any short comings of the design, which will then be dealt with.
43 Create Test Log
AIM:
To list all tests performed, and some basic information about each one.
DESCRIPTION:
This document is necessary to show recording and proof of work.
Date: 31 Mar 2011
44 Perform Design Modifications And Improvements
AIM:
Make changes to bring the system up to compliance with the customer requirements
DESCRIPTION:
All changes that are made must be recorded in the CAD drawings.
45 Upgrade Software For Improvements
AIM:
Make changes to software code to make the Ground Vehicle behave better.
DESCRIPTION:
Many tweaks will be possible once a good feel for how the system behaves as a whole has been
obtained. Flaws in the software can then be patched up.
Date: 31 Mar 2011
46 Generate Final Design Document
AIM:
Produce the final designs of the Landshark Project
DESCRIPTION:
Once all the final changes have been made, the system as it now is will be show in full detail in
this document.
MEMBER RESPONSIBLE: Damian Mew, Joshua Lok
47 Perform Final Testing Against High Level Test Descriptions
AIM:
To ensure the whole system does work as required, and to avoid any embarrassingly obvious
failures that should have been picked up in testing.
DESCRIPTION:
This will very much be a repeat of the previous tests, although all Test Cases must pass.
Date: 31 Mar 2011
48 Update Test Logs
AIM:
Complete the Test Logs.
DESCRIPTION:
With the final private tests now complete, the Test Log can be wrapped up.
49 Perform Acceptance Test on LS Systems
AIM:
Present completed project to Project Supervisor.
DESCRIPTION:
Prove to Project Supervisor that the Landshark Project is now ready for presentation and delivery
to customer.
MEMBER RESPONSIBLE: Whole Team, Jason Ford
Date: 31 Mar 2011
50 Generate Operators Manual
AIM:
Create document to make handover of the Landshark Project smooth to the customer.
DESCRIPTION:
This document will make the user intelligent to the proper use of the Landshark Project.

Work Package Description: Landshark

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Work Package Description: Landshark

Uploaded by

Copyright:

Available Formats

Doc No: LS-PRP-PRJ-02

QUT Avionics Issue: 1.0

“A QUT Avionics Project”

Prepared by Date _______________

Checked by Date _______________

Approved by Date _______________

Authorised for use by Date _______________

Telephone (+61 7) 3138 2207

Document Description of Change Date Approved

Name Affiliation Distribution Approved

3 Documentation Numbering Scheme......................................................................................10

4 Work Packet Descriptions (WPD).........................................................................................11

2.1 QUT Avionics Documents

1 LS-PRP-PRJ-01 (Project Management Plan)

2.2 Non-QUT Documents

3 Documentation Numbering Scheme

<Project Name> - <Project Functional Group> - <Document Type> - <sequence number>

Valid Project Name

Valid Project Functional Group (3 characters)

PRP Project Planning

PRJ Project Management Plan

Table 3-1 - Documentation Numbering Convention

4 Work Packet Descriptions (WPD)

4.1 Conception (Pre-System Definition)

5 Define Customer Requirements

To list what the customer wants from the project.

DATE COMMENCED: N/A

DATE COMPLETED: 10/12/2010

MEMBER RESPONSIBLE: Paul

6 Generate Derived Requirements Document

DATE COMMENCED: 10/01/2011

DATE COMPLETED: 24/01/2011

MEMBER RESPONSIBLE: Joshua Lok

7 Generate Conceptual Design Document

To show the high level view of the Landshark system.

DATE COMMENCED: 10/01/2011

DATE COMPLETED: 24/01/2011

MEMBER RESPONSIBLE: Damian Mew

8 Generate Health and Safety Risk Management Document

DATE COMMENCED: 24/01/2011

DATE COMPLETED: 07/02/2011

MEMBER RESPONSIBLE: Joshua Lok

9 Generate Work Breakdown Structure Document

DATE COMMENCED: 24/01/2011

DATE COMPLETED: 21/02/2011

MEMBER RESPONSIBLE: Damian Mew

10 Generate High Level Test Descriptions Document

To determine how each of the customer requirements will be tested.

DATE COMMENCED: 07/02/2011

DATE COMPLETED: 21/02/2011

MEMBER RESPONSIBLE: Daniel Ginn

11 Generate Configuration Management Document

This document will explain the processes used in this project.

DATE COMMENCED: 07/02/2011

DATE COMPLETED: 21/02/2011

MEMBER RESPONSIBLE: Daniel Ginn

12 Generate Work Package Description Document

DATE COMMENCED: 07/02/2011

DATE COMPLETED: 07/03/2011

MEMBER RESPONSIBLE: Daniel Ginn

13 Generate Project Risk Management Document

To list possible problems in the project, and the mitigate them.