LIQUID LEVEL DETECTOR
PRODUCT DESIGN SPECIFICATION
Khaleel Alkhabbaz
Nicholas Klein
Timothy Arellano
Truong Pham
Tuan Nguyen
Version 1.2
10/23/2013
Liquid Level Detector
VERSION HISTORY
Version
#
0.5
1.0
1.1
1.2
Implemented
By
Nick Klein
Tim Arellano
Nick Klein
Revision
Date
10/23/13
10/23/13
10/23/13
Nick Klein
10/23/13
Reason
Initial Design Definition draft
Added section 4: Product Requirements
Changed 1/8th to 1/10th in regards to LED
measurement increments.
Added Group Member’s names to cover
sheet
Page 2 of 18
Revision 1.2
Liquid Level Detector
TABLE OF CONTENTS
1 INTRODUCTION .................................................................................................................... 4
1.1
Purpose of The Product Design Specification Document ......................................... 4
2 GENERAL OVERVIEW AND DESIGN GUIDELINES/APPROACH ............................ 4
2.1
Assumptions / Constraints / Standards ...................................................................... 5
3 ARCHITECTURE DESIGN ................................................................................................... 6
3.1
Logical View ............................................................................................................. 7
3.2
Hardware Architecture ............................................................................................ 11
3.3
Software Architecture ............................................................................................. 13
3.4
Performance ............................................................................................................ 13
4 PRODUCT REQUIREMENTS ............................................................................................ 14
4.1
Use-Cases ................................................................................................................ 14
4.2
Product Musts .......................................................................................................... 15
4.3
Product Shoulds ....................................................................................................... 16
4.4
Product Mays ........................................................................................................... 17
4.5
User Interface overview .......................................................................................... 17
5 PRODUCT DESIGN SPECIFICATION APPROVAL...................................................... 18
Page 3 of 18
Revision 1.2
Liquid Level Detector
1
1.1
INTRODUCTION
PURPOSE OF THE PRODUCT DESIGN SPECIFICATION DOCUMENT
The Product Design Specification document is meant to provide project management and
design team with direction on how to proceed with prioritizing product features and design
decisions based on “Must”, “Should”, and “May” declarations that refer to what a product
must, should and may do. This document provides the requirements that a product will be
measured against during and after the product launches to gauge if product development
was successful and within the parameters established at the beginning of the product
discussion and development.
2
GENERAL OVERVIEW AND DESIGN GUIDELINES/APPROACH
The Product must meet the requirements specified in section 4 of this document as well as
the requirements mentioned in Andrew’s slides during the second day of class in ECE411.
This includes requirements such as the product at minimum must have one actuator, one
input, and one processor. These basic requirements drive the approach to the problem. The
approach will be once a product has been defined to determine which MCU is sufficient to
fill this role. Since a processor come in all shapes and sizes this will be a critical
component in determining the cost of the system.
Page 4 of 18
Revision 1.2
Liquid Level Detector
2.1
ASSUMPTIONS / CONSTRAINTS / STANDARDS
We are constrained by the fact we have rigid requirements in the practicum project
requirements document. The constraints of our design are we will need to make certain
decisions and justifications as are listed in section 4 of this document. The other constrains
that have been given to us are defined in this section by Andrew.
If you go to this link: http://web.cecs.pdx.edu/~faustm/ece411/homework/projectspecification.pdf
You will find these restrictions:
◦ Design
▪ Have ≥ 1 sensor.
▪ Have ≥ 1 actuator.
▪ Have a digital or analog processor.
◦ Schematic
▪ Be in a schematic capture program.
▪ Be forward/backward annotated to your PCB design.
◦ PCB
▪ Have ≥ 25% surface mount components (NB: “assembled by hand” below).
▪ Be a 2 layer PCB with solder mask and top-side silk screen.
▪ Have the processor on your PCB (i.e., PCB may not be a daughter boards or
“shield”).
◦ Assembly and debug
▪ Be assembled by hand (your hand).
▪ Be tested.
▪ Work.
◦ Documentation
▪ Be documented.
▪ Have all documentation and design files in a revision control program.
▪ Use collaborative documentation tools (e.g., Redmine wiki, Google Docs)
◦ Be safe
Page 5 of 18
Revision 1.2
Liquid Level Detector
3
ARCHITECTURE DESIGN
This program will utilize over the counter parts as a part of the design. We must select
components that are readily available to us in the off chance that something goes wrong
and we fry a part. Time to market and lead time are critical components in this project as
we only have 10 weeks to complete it. We will be utilizing Atmel for our processor, over
the counter buttons and LED displays. The key component that we will need to order is the
Ultrasonic sensor. These types of sensors are widely available however they are generally
only available online. We have a “should” statement that the sensor needs to be
waterproof. Waterproofing sensors will lead to additional cost to the end product so design
tradeoffs may occur since we are poor college students.
Page 6 of 18
Revision 1.2
Liquid Level Detector
3.1
LOGICAL VIEW
MUST HAVE diagram
LED
level
Output
Input
Cylinder
(8oz)
Input
All logic relies on:
MCU
Analog components
(Filter caps,
Batteries, etc.)
Page 7 of 18
Revision 1.2
Button
Liquid Level Detector
Project must have two inputs:
– Buttons
• One to turn on device.
– Level Sensor (Ultrasonic)
Project must have one output:
– LED bar graph
• Increments of 1/10th
Page 8 of 18
Revision 1.2
Liquid Level Detector
SHOULD HAVE diagram
LED
level
Output
LCD
screen
Output
Input
Cylinder
(8oz)
Button
Input
MCU
Input
Button
All logic relies on:
Analog components
(Filter caps,
Batteries)
Page 9 of 18
Revision 1.2
Liquid Level Detector
Project should have three inputs:
– Buttons
• One to turn on device.
• One to swap between LED bar graph and LCD display
– Level Sensor (Ultrasonic)
Project should have two outputs:
– LED bar graph
• Increments of 1/10th
– LCD screen
• Show Percentages of full
Page 10 of 18
Revision 1.2
Liquid Level Detector
3.2
HARDWARE ARCHITECTURE
We have selected components that are listed in the L1 Component research document on
the Wiki. The MCU is Atmel and will be programmed with the number of inputs and
outputs described in the Logical view section of this document.
Since TTM is a key factor in this design we will be trying to minimize personal design
decisions by using industry available parts. We will be looking to purchase ultrasonic
sensors, MCUs, Buttons, and LED bar graphs.
One key component in our HW design will be interfacing with the LED bar graph:
This part works by individual LEDs acting as the level on the graph such as the below
picture:
We will be required to either use multiple pins or we will need some sort of decade counter
to control this device. As of this revision 0.5 this is currently the best known component
for the job.
For the Buttons we will be using standard over the counter tactile Single pull single throw
switches. For the MCU we will be looking to use a higher pin count MCU. Originally in
Page 11 of 18
Revision 1.2
Liquid Level Detector
our project proposal we thought we could get by with the ATtiny85 however if we wanted
to use an LCD screen we would need 8 pins and for an LED bar graph depicted above we
need 10 pins. Based on this we have decided to go with the Atmega328 for a higher pin
count and would reduce the number of external components we would need such as decade
counters.
For Ultrasonic senors they typically some in a transceiver package that includes some sort
of logic that generates a 40kHz pulse. We are looking to utilize one of these packages. Our
preliminary research turned up the parallax ultrasonic sensor:
This device produces a proportional response on the Signal pin in relation to what it
receives on the TX/RX speakers depicted above. One limitation of the device is it runs on
5.00V we are looking for a component that runs on a 3.30V coin cell battery. This in mind
we ended up looking in to the MB1030 depicted below:
This sensor operates on a lower voltage, has a lower footprint, and more options on getting
the data from the range finder. We are still on the fence about which component to
purchase so a later revision of this document will describe which piece of hardware we
went with and why we selected it.
Page 12 of 18
Revision 1.2
Liquid Level Detector
The reader should be aware of how these decisions are being made. The end goal of this
project is to have an ultrasonic sensor that measures the distance between the sensor and
the top of the liquid and gives a reading based on a uniform container and the energy
returned by the ultrasonic pulse. After utilizing some mathematics we can determine the
volume of the container.
3.3
SOFTWARE ARCHITECTURE
For this design will be utilizing C code to program the MCU. The reason for this is C is
widely used and for these sensors we can find example code that can speed time to market.
3.4
PERFORMANCE
Since the intention of this design is to ultimately provide a value alternative to current
industry standards of measuring containers a key performance feature will be accuracy and
efficiency of the design. As a must the product must be within 20% of actual
measurements. There are additional stretch goals for this measurement that are listed in
section 4 of this document.
Page 13 of 18
Revision 1.2
Liquid Level Detector
4
4.1
PRODUCT REQUIREMENTS
USE-CASES
This product is intended to be used wherever liquid level measurement is desired. This can
include, but is not limited to; gas tanks, water tanks, septic tanks, and hot water heaters. It
is our goal to make a system that is robust enough to be used in most any environment and
provide reasonable accuracy (within 5-10%). Ideally we want to be able to use this in
opaque containers or where visual observation of liquid levels cannot be ascertained.
Page 14 of 18
Revision 1.2
Liquid Level Detector
4.2
PRODUCT MUSTS
The following table lists the Must haves for this product. This includes features and items
that ensure a working product, but do not ensure a user friendly product. These are the
bare-bones requirements for this product as well as the practicum project.
Project
Requirements:
What Must it do
Justification
Priority
Read liquid level
Primary feature of design without
this the design wouldn’t exist.
1
Report liquid level
as percentage (LED
bar graph)
Provide visual feedback to user in
the terms of percent of remaining
liquid.
1
Have an MCU
Practicum design requirement. Main
function must be driven by an MCU
1
>25% SMD
Practicum design requirement. Must
be composed of more than 25%
surface mount components.
1
Hand assembled
Practicum design requirement. The
main limitation is no BGA parts
1
Must be reasonably
accurate (20%)
Provides validity to measurements.
1
Affordable
We're poor college students
1
MUST work
Practicum design requirement to
receive a passing grade
1
1. Absolutely necessary for successful completion of project. This also includes any
requirements for the Practicum project to receive a passing grade (i.e. Must work)
2. These are high priority items that will make the product more robust or more user friendly.
These are not absolute needs but require strong consideration
3. These are features that should be looked at, time permitting. These will add features to make
the product more desirable but are not necessary in the root functioning of the product.
4. These are stretch goals that should only be looked at if we complete priority 3 items.
Page 15 of 18
Revision 1.2
Liquid Level Detector
4.3
PRODUCT SHOULDS
This section outlines the parts of the product that would be nice to have but are not
absolutely necessary for the product to work. These include items like user friendliness,
actual amount readouts (liters instead of percentages), etc. These items will be a high
priority but will be overlooked if necessary for timely completion of the product.
Project Requirements:
What Should it do
Justification
Priority
Waterproof
Protection from exposure to the
liquid being measured. Sensor will
be inside of a liquid container
2
Enclosure should be
able to withstand
reasonable impact (Fall
from 3 meters)
Prevents premature failures from
short falls or impacts due to user
error or shipping.
2
Have an LCD readout
Provides options for: user
friendliness, more feedback
options (L instead of %),
expandability (can add
environmental sensors such as
temperature)
3
PCB should have
scalability options
(connections for LCD,
etc.)
Allows use of one PCB for
incremental featuring.
2
Be chemical and
temperature resistant
small/compact
Must be more accurate
(5-10%)
Protects the circuit from
measuring non-water substances at
various temperatures.
Ideally allow to fit under a gas
cap/container lid. Smaller the PCB
= lower cost
Gives validity to measurements.
2.
3.
4.
3
2
Give option to wake from "sleep"
state. Reduce overall power
2
consumption of device
Absolutely necessary for successful completion of project. This also includes any
requirements for the Practicum project to receive a passing grade (i.e. Must work)
These are high priority items that will make the product more robust or more user friendly.
These are not absolute needs but require strong consideration
These are features that should be looked at, time permitting. These will add features to make
the product more desirable but are not necessary in the root functioning of the product.
These are stretch goals that should only be looked at if we complete priority 3 items.
respond to user input
(button)
1.
3
Page 16 of 18
Revision 1.2
Liquid Level Detector
4.4
PRODUCT MAYS
This section outlines the features of the product that are really nice to have. They are the
least necessary to the success of the product and only serve to increase user experience. For
this product user experience isn’t our main focus, but we will look into it, time permitting.
This feature set includes optimizing the product for specific uses, such as a motorcycle fuel
gauge.
Project Requirements:
What Might it do
Justification
Priority
fit under a lid/gas cap
Allows for use model in a
motorcycle fuel gauge application.
4
power efficient
Reduce the battery requirements
for the design. Increase battery
life.
4
Must be absolutely
accurate (0-5%)
Gives validity to measurements.
4
Give more options for usability
such as continuous or timed or
4
button press only readings.
Absolutely necessary for successful completion of project. This also includes any
requirements for the Practicum project to receive a passing grade (i.e. Must work)
These are high priority items that will make the product more robust or more user friendly.
These are not absolute needs but require strong consideration
These are features that should be looked at, time permitting. These will add features to make
the product more desirable but are not necessary in the root functioning of the product.
These are stretch goals that should only be looked at if we complete priority 3 items.
respond to user input for
multiple operation states
1.
2.
3.
4.
4.5
USER INTERFACE OVERVIEW
The main focus in user interface is to make it as intuitive as possible while providing the
most feature rich experience. User interface will consist of at least one button that will
serve as a reading. The system will remain idle until the button is pressed and only then
will the system take a reading of the liquid remaining in the container. Other design
updates may include a hard power switch to remove the power source from the circuit in
order to reduce leakage power loss when idle. More operation stages may be included in
later revisions, as well, to include continuous mode, burst (timed) mode, etc.
Page 17 of 18
Revision 1.2
Liquid Level Detector
5
PRODUCT DESIGN SPECIFICATION APPROVAL
The undersigned acknowledge they have reviewed the Product Design Specification
document and agree with the approach it presents. Any changes to this Requirements
Definition will be coordinated with and approved by the undersigned or their designated
representatives.
Signature:
Date:
Print Name:
Title:
Role:
Signature:
Date:
Print Name:
Title:
Role:
Signature:
Date:
Print Name:
Title:
Role:
Signature:
Date:
Print Name:
Title:
Role:
Signature:
Date:
Print Name:
Title:
Role:
Page 18 of 18
Revision 1.2