| Repository | Project Overview | Prototype | Team |
|---|---|---|---|
| - Google Drive - Wiki - Timeline - Tools |
- Project Brief - Client's Vision - Project Purpose - Project Scope - Stakeholders - Risks and Constraints |
- Requirements - Market Research - Resources and Costs - System Architecture - Prototype |
- Contributors - Feedback - Meetings |
| Audit | Communication | Feedback | Poster | Prototype | Report | Team |
|---|---|---|---|---|---|---|
| - Audit 1 - Audit 2 - Audit 3 |
- Evidence | - Audit 1 - Audit 2 - Progess |
- Posters - Final Poster |
- Plan - Changelog - Experiement - Progress |
- Report - Material |
- Audit 2 Timeline - Audit 3 Timeline - Team Roles |
Please note that Google Drive navigation are linked to the online Google Drive, not the GitHub version.
Thales' vision is to develop a tracking system to improve safety and efficiency of their personnel and equipment in dangerous environments such as mines and oil rigs. The clients expressed a broad scope for the project which was deemed difficult to complete in the given timeframe. The focus of the project revolves around two unique parts:
-
Market analysis
- What technologies are currently available that may address this problem?
- Is it possible to develop a solution utilising COTS components?
- Are there other organisations working in this area? -
High level architectural design of the solution including but limited to
- Requirements generation/analysis
- Functional flow/functional breakdown
- System/Subsystem interfaces
- Rapid prototyping to test ideas (evolve and iterate)
The main prupose of the project is to analyse the market situation of employee or asset tracking devices by providing a report to Thales. This is the amin aspect of the project which Thales is particularly interested in as it will provide value to the company. Furthermore, the team must develop and prototpye a relevant product that fit the requirements in a viable method (i.e. cost-effective and usable).
The team decided to significantly narrow the initial scope of the project, which included emplyee and asset tracking within an oil rig and/or a mine. Throguh group meetings, we firstly decided to work on only oil rigs, thus having a stable platform to design our product. Still having a broad scope for the timeframe, the team made decisions on a tracking device which connects via radio to a receiver. This device aims to have functions which other devices on the market do not, thus improving upon them.
The key points outlined below show high level requirements for the project that can be futher broken down into sub-requirements.
-
Personnel Tracking
The tracking and the monitoring of personnel must be prioritised. Furthermore, their locations must be accessible in real time by relevant site supervisors for safety purposes. -
Equipment Tracking
The system should also be attachable to larger pieces of equipment which allows tracking of said equipments. This will lead to improvements in efficiency and management of an oil rig. -
Asset Location Analysis
The system will provide analysis tools for data collection. For example, the system should be able to provide information on patterns detected for activities such as:
* Personnel Movement
* Equipment Movement
* Safety Hazards
This information will then be used to improve efficiency and safety in an oil rig. -
Seawater Detection
The system should detect if any personnel has fallen off the oil rig into the ocean.
In-depth analysis on stakeholders is documented in our wiki.
Market Research Report
Market research report that provides context into the importance of personnel safety in an oil rig environment followed by a preliminary market research into the development of a personnel/asset tracking system.
The key requirements of the system include (1) tracking asset and personnel locations, (2) assisting with evacuation or rescue protocols, and (3) monitoring worker fatigue levels. Market reserach has found that the personnel/asset tracking market sector is a highly saturated one.
However, a requirements based approach, followed by the comparison of various commercial off-the-self (COTS) system, suggests that there are areas in which existing systems could be improved in order to satisfy the clients' requirements better and also ensure that the system is well-suited to an oil rig environment.
The original funding on the project was 100 AUD, however the this may vary depending on the scope of the projecct and may increase with proper cost analysis.
The main resources required for the project include the following:
| Item | Amount | Price (each) | Price (total) | Supplier | URL |
|---|---|---|---|---|---|
| Arduino Uno | 2 | $16.45 | $32.90 | Aus Electronics Direct | url |
| Arduino 3 Axis Accelerometer | 1 | $5.45 | $5.45 | Aus Electronics Direct | url |
| Wireless Transmitter | 1 | $13.95 | $13.95 | Jaycar | url |
| Wireless Receiver | 1 | $13.95 | $13.95 | Jaycar | url |
| Arduino Water/Liquid Sensor Module | 1 | $2.15 | $2.15 | Aus Electronics Direct | url |
| Hook-Up Wire Pack - 2 metres | 1 | $4.95 | $4.95 | Jaycar | url |
| Universal Pre-Punched Experimenters Board - Small | 3 | $4.50 | $13.50 | Jaycar | url |
| 1/4 Watt Carbon Film Resistors - 300 Pieces | 1 | $8.95 | $8.95 | Jaycar | url |
Total: $95.80
Updated to v2.0
The purpose of the rapid prototype in this project is to validate models and validate claims made by COTS products. Below shows a number of iterations of the prototype:
Testing of received signal strength in different environments to simulate an oil rig. This test will then be used to analyse the claims made by COTS products. This iteration will also be used to analyse the path loss models.
In this iteration, the two Arduinos and the wireless transmitters and recievers will be used. The system can also use path loss model to determine the distance from the transmitter to the reciever.
Addition of an accelerometer to the system as a way of detecting a falling personnel. This iteration is to add the accelerometer to the transmitter to compliment the distance tracking.
Addition of a water sensor to determine if a personnel has fallen into the ocean. The concept behind this iteration is that if the water sensor detects water after the accelerometer has detected a fall, the transmitter will send an alert to the network.
The majority of the risks the team will face is in the prototype stage since one minor failure in the components may lead to a catastrophic failure in the entire design. These risks include:
- The device must not fail at any circumstances since this may lead to catastrophic outcomes.
- The device must be waterproof, as a major aspect of our design invlovles its submersion in water. All components of the design must be waterproof so the device does not malfunction.
- The device must be eqipped with a battery that enables at least a full day's worth of function.
Our team communicated with Thales to refine our project after the first audit to ensure the team follows the right path. Risks and constraints stated from the past audit have been significantly altered to represent a refined idea of the project.
In-depth analysis on feedback is documented in our wiki.
Meetings: Schedule
Certain meeting notes are not available for public viewing as they contain sensitive information that is cannot be disclosed.
Team gathers for weekly meetings, usually at the time of 8:00am - 10:00am on Wednesdays. The meetings consist of discussions of weekly tasks and goals as well as personal and team performance. This allows struggling members to get help from the team and fairly distribute workload for the week.
During weekly tutor meetings, the team either performs an audit presentation or inform the tutor and the shadows of our progress. The tutor and oberservers will then provide recommendations allowing us to improve upon our work.
The team meetings with the clients fornightly to discuss the project. In this time, the team communicates with the client by asking questions and receiving feedback regarding the project. These meetings are held in Thales office complex off-campus for the convience of the clients.
Updated to v1.2
| Name | Uni ID | Role | Contact |
|---|---|---|---|
| Alisha Boniface | u5799388 | - Hardware - Scheduling - Quality Control |
|
| Dillon McGrath | u5784121 | - Hardware - Ergonomics - Meeting Scribe |
|
| Franklin Wilson | u5801853 | - Team Communication - Hardware - Audit Slides |
|
| Jordan Schaeffer | u5800267 | - Hardware - Software - Parts |
|
| Rob Whittaker | u5589395 | - Team Manager - Software - Repo Maintenance |
|
| Woojin Ra | u6058768 | - Client Communication - Software - Repo Maintenance |
GitHub The team decided to utilize the issues function in GitHub as one of our main management tools. The team will rearrange issue cards between columns that represent "To Do", "In Progress", "Done" and such. Furthermore, the source code and certain documents will be stored on GitHub in the interest of parallel workflow.
Coding Language When building the prototype (estimated at week 7) our team will need to program some code. To do this our team is required to choose a programming language in which to program with. At this point in time it seems that the most likely language that we will use will be C. C is the most common language that the majority of the team have experience in. Another benefit is that it has applications in software and embedded hardware applications.
Google Drive Google drive will be used to manage documents containing research, meeting notes, planning, decisions and more. It will be separated into a private and public section to ensure the security of any confidential information provided by Thales. Only the public section will be available for viewing by observers.
Slack Our team has decided to use Slack as the main communication mechanism for team members. We found that it was best to have multiple different channel for different topics. This made it easier for us to keep track of conversations.