Lab 2 – DFM Prototype Product Specifications, David Ballentine
Lab 2 – DFM Prototype Product Specifications
David Ballentine
CS411
Janet Brunelle
March 5, 2007
1
Lab 2 – DFM Prototype Product Specifications, David Ballentine
2
TABLE OF CONTENTS
1
INTRODUCTION ................................................................................................................ 3
1.1
1.2
1.3
1.4
1.5
2
PURPOSE .......................................................................................................................... 4
SCOPE .............................................................................................................................. 5
DEFINITIONS, ACRONYMS, AND ABBREVIATIONS ............................................................ 7
REFERENCES .................................................................................................................... 7
OVERVIEW ....................................................................................................................... 8
GENERAL DESCRIPTION ................................................................................................ 8
2.1
PROTOTYPE ARCHITECTURE DESCRIPTION ...................................................................... 9
2.2
PROTOTYPE FUNCTIONAL DESCRIPTION ........................................................................ 10
2.3
EXTERNAL INTERFACES ................................................................................................. 13
2.3.1 Hardware Interfaces ................................................................................................. 13
2.3.2 Software Interfaces ................................................................................................... 14
2.3.3 User Interface ........................................................................................................... 14
3
SPECIFIC REQUIREMENTS .......................................................................................... 14
3.1
FUNCTIONAL REQUIREMENTS ........................................................................................ 14
3.1.1 Individual Sensor Test............................................................................................... 14
3.1.2 Sensor Combination Test .......................................................................................... 14
3.1.3 Data Input Test ......................................................................................................... 15
3.2
PERFORMANCE REQUIREMENTS ..................................................................................... 15
3.2.1 Sensors ...................................................................................................................... 15
3.2.2 Algorithm .................................................................................................................. 15
3.3
ASSUMPTIONS AND CONSTRAINTS ................................................................................. 15
3.4
NON-FUNCTIONAL REQUIREMENTS ............................................................................... 17
3.4.1 Security ..................................................................................................................... 17
3.4.2 Maintainability.......................................................................................................... 17
3.4.3 Reliability .................................................................................................................. 17
4
APPENDIX .......................................................................................................................... 18
LIST OF FIGURES
FIGURE 1. KIDS AND CARS CHILDREN FATALITY DIAGRAM (KIDS AND CARS, 2007)...................... 4
FIGURE 2. PROTOTYPE MAJOR FUNCTIONAL COMPONENT DIAGRAM. ............................................. 6
FIGURE 3. DFM ALGORITHM. ........................................................................................................ 10
FIGURE 4. LIFE DETECTION ALGORITHM. ...................................................................................... 11
FIGURE 5. DFM ACTIVATION. ....................................................................................................... 13
LIST OF TABLES
TABLE 1. FEATURES COMPARISON TABLE. ...................................................................................... 9
TABLE 2. HARDWARE PRIORITY LIST. ........................................................................................... 12
TABLE 3. ASSUMPTION, CONSTRAINT, DEPENDENCY TABLE ......................................................... 16
Lab 2 – DFM Prototype Product Specifications, David Ballentine
1
3
INTRODUCTION
In 2004, a baby girl died after being left alone inside a vehicle for more than three hours
(Staff, Wire Reports, 2004). More recently in 2007, in Tennessee, a baby boy also died after
being left in a vehicle. (Associated Press, 2007). In this case, the father was charged with
negligent homicide. Every year, children are accidentally left alone in vehicles. A great number
of reasons including a change in the parent’s schedule, a quick stop turning into a long ordeal, or
even while taking care of another emergency, can cause a parent to accidentally leave a child
behind (David Ballentine, 2008).
Unfortunately, deaths occur when conditions inside the vehicle become too hostile. The
vehicle becomes a prison to a child as the child, being too young, is unable to escape. The most
common factor is heat. Body temperatures above 104°F are life threatening, while at 106°F
brain death begins. A temperature of 113°F is almost certain death. Inside a standard vehicle on
a moderate spring day of 85°F, the inside of the car will reach 100°F in just seven to ten minutes,
and 100°F in just half an hour. If the outside temperature is around 100°F, than the internal
temperature will reach 140°F in just under 15 minutes (EPA, 2006). A vehicle has the potential
to become inhospitable in a very short amount of time, thus leaving any children left inside to a
torturous death (David Ballentine, 2008).
Figure 1 indicates that the two most prominent fatalities involving children, not including
crash victims, are the child being backed over by the vehicle and the child being left inside and
dying from the hot weather. The first problem, the child being run over, is currently being
addressed by the vehicle industry by attaching rear view cameras to the back of vehicles. This
document addresses how the second problem, the child being left in the vehicle, can now be
Lab 2 – DFM Prototype Product Specifications, David Ballentine
4
addressed with the Don’t Forget Me system (DFM system) by utilizing a system of sensors,
alarms, and algorithms (David Ballentine, 2008).
Figure 1. Kids and Cars Children Fatality Diagram (Kids and Cars, 2007)
1.1 Purpose
The DFM system is a life saving tool utilizing sensor technology designed to prevent an
occupant from being left behind in a vehicle. The system will be implemented into vehicles at
the time of their manufacture. In a vehicle installed with a DFM, the system will be active at any
time the car is parked, including when the car itself is off. Utilizing hardware sensors such as a
pressure sensor, a motion sensor, and a heartbeat sensor, the software algorithm will calculate the
probability of an occupant being in the seat. It will also calculate how far the driver is from the
Lab 2 – DFM Prototype Product Specifications, David Ballentine
5
vehicle by measuring the signal strength of a transmitter on the vehicle key (David Ballentine,
2008).
When the DFM system concludes that there is an occupant in the seat, and if the driver is
more than twenty feet away from the vehicle, the vehicle’s alarm will sound. There is the option
to temporarily disable the alarm. A switch on the occupant’s seat will turn off the alarm. The
driver or a child old enough can activate this switch. The deactivation of the switch will cause
the system to enter standby mode. It will continue to monitor the occupant, as well as the
conditions inside the car. If the conditions become too hostile, the alarm will sound again. This
time it will not be possible to turn the alarm off without the occupant being removed from the
vehicle (David Ballentine, 2008).
1.2 Scope
The prototype of the DFM system will encompass almost everything that will be on the
final product, except on a smaller scale. The prototype will also have a major Graphical User
Interface (GUI) to show exactly what is going on at the sensor level. The user will also be able
to change certain variables, for example the temperature, and witness the results. Figure 4 shows
the setup of the prototype components. The diagram is similar to the final product with a few
notable changes such as using LabVIEW combined with a data acquisition devise (DAQ) for
sensor input (David Ballentine, 2008).
Lab 2 – DFM Prototype Product Specifications, David Ballentine
Figure 2. Prototype Major Functional Component Diagram.
6
Lab 2 – DFM Prototype Product Specifications, David Ballentine
7
1.3 Definitions, Acronyms, and Abbreviations
Accelerometer Sensor: Used to detect vibrations. In this application it is used to detect a
heartbeat.
DAQ: Data acquisition devise. A hardware devise used to send and receive computer signals
from external electronic devises.
GUI: Graphical User Interface. A display on a computer that uses graphics to display content
and can allow user manipulation.
LabVIEW: A graphical programming tool allowing for the display and acquisition of data from
a great deal of devices including external hardware.
Pulse Oximeter: A devise used to measure oxygen in a person’s blood stream.
1.4 References
Associated Press. (2007). Baby Left in Car Dies from Heat. Retrieved October 6, 2007, from
http://abclocal.go.com/wpvi/story?section=nation_world&id=5266232.
EPA. (2007). Excessive Heat Events Guidebook. Retrieved January 3, 2008, from
http://www.epa.gov/hiri/about/pdf/EHEguide_final.pdf.
Kids and Cars. (2007). Kids and Cars Children Fatality Diagram. Retrieved October 6, 2007,
from http://www.kidsandcars.org/.
Staff, Wire Reports. (2004). Baby Left in Hot Van Dies. Retrieved October 6, 2007, from
http://www.4rkidssake.org/AZ3435.htm.
Lab 2 – DFM Prototype Product Specifications, David Ballentine
8
1.5 Overview
This document provides the DFM System Prototype Product Specifications. It will detail
specifics about the design, configuration, and key features about the prototype. Also included in
this document is information about the software and hardware components involved in this
prototype.
2
GENERAL DESCRIPTION
The following will describe a few different aspects of the prototype. The architecture
description as well as and overview of the functional description will be focused on in this
section.
(This Space Intentionally Left Blank)
Lab 2 – DFM Prototype Product Specifications, David Ballentine
9
2.1 Prototype Architecture Description
The prototype will utilize several different types of technologies. It will demonstrate that
these technologies work both separately and as whole. Table 1 shows the main components of
the prototype.
Features
Prototype
Heartbeat Sensing
A pulse oximeter will be attached to a volunteer’s finger. This device will give the
same input values of the accelerometer, but will require the volunteer to attach the
device. Likewise, the presence of a pulse will be the only criteria, not rhythm.
CO2 Sensor
No CO2 sensor will be used for the prototype, rather the sensor will be simulated in
LabVIEW.
Temperature Sensor
Motion Sensor
A temperature sensor will read the current temperature of the room and indicate when
the level becomes too dangerous for a human.
The motion sensor will read in several values over a short time period. If motion is
detected over that time period, then the software will assert that a person is present.
Pressure Sensor
The sensor will be placed under a cushion for the volunteer to activate. By sitting he or
she will activate the pressure sensor. This would simulate a child sitting in a rear or
safety seat.
Microcontroller/CPU
LabVIEW simulation software will be run in order to implement all the logic necessary
to run the DFM system. Rather than have the sensors wired into a microcontroller, they
will interface with the underlying software using an input/output device known as a
DAQ.
Reset Switch
A switch will be added to the set of hardware, but the logical implementation will not
be as elaborate.
Infrared
Reciever/Transmitter
The same implementation will take place, but the generator will not be in the form of a
key fob.
Alarm
A small speaker will be used to generate noise and indicate the alarm. A car alarm will
not be necessary to demonstrate.
Microphone
The computer's microphone will be used in LabVIEW to determine if the decibel level
has reached a predefined level.
Table 1. Features Comparison Table.
Lab 2 – DFM Prototype Product Specifications, David Ballentine
10
2.2 Prototype Functional Description
The major functional components are described separately in Table 1 above. When placed
within the DFM system though, they work in unison based on an algorithm. Figure 3 shows a
basic overview of how the DFM system works
Figure 3. DFM Algorithm.
As this diagram shows, there are three main paths to get to the alarm. The top path
determines if there is a dangerous temperature inside the vehicle. It does this simply by checking
the temperature sensor. If the temperature is below or above a certain point, this path will be
triggered. For demonstrational purposes the high temperature will be 90 degrees Fahrenheit
while the low temperature will be 30 degrees Fahrenheit.
Lab 2 – DFM Prototype Product Specifications, David Ballentine
11
The bottom path works with the key fob. If the key fob signal is weakened to a certain
point, this will mean that it is 20 feet or more away from the vehicle. If this happens then this
bottom path is triggered
The middle path is the Detect Life path. Both the top and bottom paths are dependant
upon this middle path. What this means, is that life must always be present if the alarm is to
sound. If this path is triggered, then either the bottom or the top path may be triggered for the
alarm to sound. The dotted box in this path is put into more detail in Figure 4.
Figure 4. Life Detection Algorithm.
Figure 4 provides a detailed look at how the DFM system determines if there is an
occupant present inside the vehicle. The system works on a weighted algorithm. Each sensor is
assigned a value. Table 2 displays which value each sensor holds. For every sensor that is
Lab 2 – DFM Prototype Product Specifications, David Ballentine
12
tripped, this value is assed to the accumulate detection value. If this value is greater than 5, the
system determines that there is life present.
Sensor
Priority Value
Pulse Sensor
4
Motion Sensor
3
CO2 Sensor
3
Pressure Sensor
2
Microphone
1
Table 2. Hardware Priority List.
In Figure 3, the other dotted box is around the activation sequence. During activation, the
DFM system will perform a check with all of its sensors. If there is a problem detected, it will
display a dashboard light informing the user that there is a problem. Figure 5 details the
specifics of how this algorithm works.
(This Space Intentionally Left Blank)
Lab 2 – DFM Prototype Product Specifications, David Ballentine
13
Figure 5. DFM Activation.
2.3 External Interfaces
The DFM System will provide several hardware and software interfaces although the
majority of the system is designed to run automatically. This section will describe the interfaces
used in the prototype.
2.3.1 Hardware Interfaces
The hardware interfaces in the DFM system include three things. The first is the key fob.
While this devise cannot be directly interfaced, the user does control its location. If it is over 20
feet from the car, the devise will activate. The second devise is the switch to temporarily disable
the alarm. The third is starting the vehicle itself. This will reset the DFM system.
Lab 2 – DFM Prototype Product Specifications, David Ballentine
14
2.3.2 Software Interfaces
The DFM prototype will be run using LabVIEW. This will provide a software interface
to observe what exactly is going on with each individual sensor.
2.3.3 User Interface
While the system works primarily from interpreting sensor readings, sometimes test cases
will need to be entered. For the prototype, a user will be able to enter in test sample for any of
the sensors provided. The algorithm will still act as though these readings were read in from the
sensors.
3
SPECIFIC REQUIREMENTS
The following information provides specific information about the prototype. Functional
requirements, performance requirements, assumptions and constraints, and non functional
requirements will all be covered in this section
3.1 Functional Requirements
This section details the functional requirements of this system. This will serve to better
break down the functions in the prototype.
3.1.1 Individual Sensor Test
1) Each sensor read in data independently
2) Display this data to the screen in an easy-to-read view.
3.1.2 Sensor Combination Test
1) The sensors will work in a combined format.
Lab 2 – DFM Prototype Product Specifications, David Ballentine
2) The algorithm will trigger if and when the alarm will sound.
3.1.3 Data Input Test
1) Each sensor can be overridden
2) Data can be read in manually or through a datafile
3.2 Performance Requirements
The following is a set of requirements to measure the performance of the prototype.
During the testing of the prototype, test cases will be used to verify the performance.
3.2.1 Sensors
1) The sensors will be able to respond within a few seconds
2) The heartbeat sensor will be able to sense a pulse from a person.
3.2.2 Algorithm
1) LabVIEW will respond to the sensors almost immediately
2) The Life algorithm will go off after the sum is greater then 5.
3) The alarm will only go off if life is detected.
3.3 Assumptions and Constraints
The prototype of the DFM System contains a couple of assumptions and constraints in
order to operate. Table 3 displays these assumptions and constraints needed in the prototype.
Also included in this list is as list of dependencies which are similar to the constraints.
15
Lab 2 – DFM Prototype Product Specifications, David Ballentine
Condition
Type
16
Effect On Requirements
30° F is the “cool” temperature
at which point alarm goes off.
Assumption
Cooling device must be present at
demonstration to lower temperature.
90° F is the “hot” temperature at
which point alarm goes off.
Assumption
Heating device must be present at
demonstration to raise temperature.
Detection of pressure indicates
detection of occupant.
Assumption
Prototype distinguishes between
pressure and no pressure; not between
different pressures.
Occupant has no remarkable
medical conditions.
Assumption
Medical conditions may affect input
from pulse oximeter.
Occupant is appropriately
dressed for the weather.
Assumption
Varied clothing affects effectiveness
of the system.
Reset switch is not used
accidentally or maliciously.
Assumption
Accidental or malicious use of the
reset switch defeats the purpose of the
system.
CO2 sensor is not incorporated
into prototype.
Constraint
Input from CO2 sensor is simulated
by the software.
Heartbeat is detected by pulse
oximeter.
Constraint
Pulse oximeter must be attached to
occupant’s finger.
Prediction of extreme
temperatures is not supported.
Constraint
Alarm is only activated if an extreme
temperature is detected.
All sensors function properly at
time of demonstration.
Dependency
Prototype cannot be demonstrated
without input from the sensors.
PC or laptop with LabVIEW
installed is available at time of
demonstration.
Dependency
Prototype cannot be demonstrated
without the LabVIEW software.
Table 3. Assumption, Constraint, Dependency Table
Most of the assumptions have to do with making sure the sensors are in a proper
environment for the prototype testing. There are also a few assumptions about the occupant not
being out of the ordinary in condition or clothing. Although in the final project this will be taken
care of, for simplicity sake of the prototype these situations will not be considered.
Lab 2 – DFM Prototype Product Specifications, David Ballentine
17
3.4 Non-Functional Requirements
The following are three non-functional requirements of the product. They are security,
maintainability, and reliability. Each of these aspects are important to the success of the product.
3.4.1 Security
The DFM system will be secure against an outside force attempting to mess with the
sensors to display false readings. Also, although the DFM system has many sensors in place
including a motion sensor and microphone, these can in no way be used to spy on the occupants
in the car. There will be no recording of actually imagery or sound in the system. The user can
feel safe that their privacy is not being invaded on.
3.4.2 Maintainability
The DFM system will maintain itself by running a series of tests on its sensors to make
sure they are all in working condition. The system will be on continuously and run a self check
every hour. If there is a problem detected, a dashboard light will light up on the dashboard of the
car. I repair service will be able to ascertain which sensor is not responding correctly and fix the
problem. As long as the user is willing to do this, the system can be maintained indefinitely.
3.4.3 Reliability
Part of the reason for the high amount of sensors in place is for redundancy and for the
system being able to adapt to a variety of situation. Even if one of the sensors fails and is not
corrected as recommended, the crippled system will still operate perfectly fine under most
normal circumstances. As stated above, if a sensor doe give out, the system will alert the user
with a dashboard display.
Lab 2 – DFM Prototype Product Specifications, David Ballentine
4
18
APPENDIX
Formal Resource Request Document:
Team: Don’t Forget Me Inc.
Project Manager: Brandon Fields
The following resources are required to be purchased for the prototype development and demonstration
of the XYZ product:
Hardware Purchase (list all items required for purchase):
Part Description
Sensor, Ultrasonic, 40Khz, Tran
Sensor, Pressure, 0-1.45 PSI
Kit, Infrared Tran and Rec
Linerar Thermistor Air Temperature
Pulse Oximeter
Part #
136654
218827
177092
OL-706
http://www.fitness-equipment.com/acatalog/
Online_Catalog_Pulse_Monitor__Ear_Clip_
for_Pulse_Monitor_1034.html
P-703A
USB-6009 Kit (LabVIEW and DAQ)
779320-22
Company
Qty Price Ea
Jameco.com
2
$7.95
Jameco.com
2
$8.99
Jameco.com
2
$24.95
Omega.com
1
$61.00
Total
$15.90
$19.98
$49.90
$68.00
FitnessEquipment
NI.com
$39.98
$331.62
2
2
$19.99
$159.00
Software Purchase (list all items required for purchase):
Part Description
FRAPS - Real-time video render
software
Part #
Company
N/A
Fraps.com
Qty
1
Price Ea
$37.00
Total
$37.00
Lab 2 – DFM Prototype Product Specifications, David Ballentine
The following University resources are required to support the prototype development and
demonstration:
1. Laptop/ Second computer
a. It will be used to display the interaction of hardware element and the
algorithm processes during the live prototype demonstration.
b. Windows XP with connection to the internet
c. Quantity: 1
d. Date required: March 1, 2008
e. Deliver to: Don’t Forget Me Inc.
2. LabVIEW installed on the Laptop
a. LabVIEW is the primary software component used in the project.
Through it the development team will interact with the hardware and
control the system algorithms.
b. LabVIEW must have the drivers installed for the DAQ used in the
prototype, a USB-6009.
c. Quantity 1
d. Date required: March 1, 2008
e. Deliver to: Don’t Forget Me Inc.
19