Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
Lab 2 – DFM Prototype Product Specifications Version 2
David Ballentine
CS411
Janet Brunelle
April 9, 2007
1
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
2
TABLE OF CONTENTS
1
INTRODUCTION................................................................................................................. 4
1.1
1.2
1.3
1.4
1.5
2
PURPOSE .......................................................................................................................... 5
SCOPE .............................................................................................................................. 6
DEFINITIONS, ACRONYMS, AND ABBREVIATIONS ............................................................ 8
REFERENCES .................................................................................................................. 11
OVERVIEW ..................................................................................................................... 12
GENERAL DESCRIPTION .............................................................................................. 12
2.1
2.2
2.3
PROTOTYPE ARCHITECTURE DESCRIPTION .................................................................... 13
PROTOTYPE FUNCTIONAL DESCRIPTION ........................................................................ 14
EXTERNAL INTERFACES ................................................................................................. 17
2.3.1
2.3.2
2.3.3
2.3.4
3
Hardware Interfaces ............................................................................................................. 17
Software Interfaces................................................................................................................ 18
User Interface........................................................................................................................ 18
Communication Protocols and Interfaces ............................................................................. 18
SPECIFIC REQUIREMENTS .......................................................................................... 18
3.1
FUNCTIONAL REQUIREMENTS ........................................................................................ 19
3.1.1
DFM System Activation Process ........................................................................................... 19
3.1.1.1
3.1.1.2
3.1.1.3
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7
3.1.8
3.2
Life Detection Procedures ..................................................................................................... 21
Environment Evaluation Procedures .................................................................................... 22
Transmitter and Receiver Functions ..................................................................................... 22
Alarm System ......................................................................................................................... 22
Reset Procedures ................................................................................................................... 23
LabVIEW Setup ..................................................................................................................... 24
Simulation Procedures .......................................................................................................... 25
PERFORMANCE REQUIREMENTS ..................................................................................... 25
3.2.1
3.2.2
DFM System Activation......................................................................................................... 25
Life Detection ........................................................................................................................ 26
3.2.2.1
3.2.2.2
3.2.3
3.2.4
3.3
3.3.1
3.3.2
3.3.3
3.4
3.4.1
3.4.2
3.4.3
Sensor Performance .................................................................................................................... 26
Procedure Performance .............................................................................................................. 26
Environmental ....................................................................................................................... 27
3.2.3.1
3.2.3.2
4
Sensor Overview ........................................................................................................................ 19
Life Detection Sensors ............................................................................................................... 20
Environmental Sensor ................................................................................................................ 21
Sensor Performance .................................................................................................................... 27
Procedure Performance .............................................................................................................. 28
Transmitter and Receiver Functions ..................................................................................... 28
ASSUMPTIONS AND CONSTRAINTS ................................................................................. 29
Assumptions........................................................................................................................... 30
Constraints ............................................................................................................................ 31
Dependencies ........................................................................................................................ 32
NON-FUNCTIONAL REQUIREMENTS ............................................................................... 33
Security.................................................................................................................................. 33
Maintainability ...................................................................................................................... 33
Reliability .............................................................................................................................. 34
APPENDIX .......................................................................................................................... 35
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
3
LIST OF FIGURES
FIGURE 1. KIDS AND CARS CHILDREN FATALITY DIAGRAM ............................................................ 5
FIGURE 2. PROTOTYPE MAJOR FUNCTIONAL COMPONENT DIAGRAM. ............................................. 7
FIGURE 3. DFM ALGORITHM. ........................................................................................................ 14
FIGURE 4. LIFE DETECTION ALGORITHM. ...................................................................................... 15
FIGURE 5. DFM ACTIVATION. ....................................................................................................... 17
FIGURE 6. LIFE DETECTION SENSORS............................................................................................. 20
FIGURE 7. ENVIRONMENTAL SENSOR. ............................................................................................ 21
LIST OF TABLES
TABLE 1. FEATURES COMPARISON TABLE. .................................................................................... 13
TABLE 2. HARDWARE PRIORITY LIST. ........................................................................................... 16
TABLE 3. FEATURES COMPARISON TABLE. .................................................................................... 29
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
1
4
INTRODUCTION
In 2004, a baby girl died due to heat 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 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 (Ballentine, David, 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 results in 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 suffer a torturous death (Ballentine, David, 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 induced conditions. 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 addressed with the Don’t Forget Me system (DFM system) by utilizing a system of
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
5
sensors, alarms, and algorithms to alert the caretaker about a potential problem (Ballentine,
David, 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. It will most likely be powered off the internal car battery, but this
will be left up to the manufacturer. In a vehicle installed with a DFM system, it 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
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
6
is from the vehicle by measuring the signal strength of a transmitter on the vehicle key
(Ballentine, David 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 (Ballentine, David 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, the temperature for example, 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 device (DAQ) for
sensor input. A detailed look at each of the components can be found in Table 3 later on in this
document. (David Ballentine, 2008).
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
Figure 2. Prototype Major Functional Component Diagram.
(This Space Intentionally Left Blank)
7
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
8
1.3 Definitions, Acronyms, and Abbreviations
Accelerometer: A device that measures the force on a sensor, primarily vibrations. Variations in
the accelerometers readings could be analyzed and to find a specific pattern such as a
heart beat or motion along a spatial axis.
Accuracy: The sensors ability to determine a correct result. Not to be confused with precision,
the exactness of the sensor’s result. Such as the thermometer reads 75.001 degrees.
Which is a precise value with +/- .001, but inaccurate given that the temperature is
actually 90 degrees.
Algorithm: A series of finite instructions that are given a particular order.
CO2: Carbon Dioxide, chemical combination for air that is exhaled. The change in the air
composition from low to high levels of carbon dioxide may indicate human respiration.
These sensors can be infrared gas sensors or chemical gas sensors.
CPU: Central Processing Unit, the device inside of a computer that executes machine code (runs
programs).
DAQ: National Instruments USB-6008 or USB-6009 Data Acquisition Device, a device that is
used to send data to a computer using an external interface, usually connected to
proprietary hardware.
DFM: Don’t Forget Me, a system designed to prevent harm to humans and animals by detecting
life and high temperatures in a vehicle.
GUI: Stands for Graphical User Interface. A display on a computer that uses graphics to display
content and can allow user manipulation.
Heartbeat Sensor: A sensor that detects tiny vibrations and determines if they match the signal
of a heartbeat.
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
9
Hyperthermia: The state at which the human body is no longer able to cool down through
natural processes. The effort the body takes to reduce heat only causes one’s temperature
to rise due to the advanced state heat exposure.
Interoperability: Interoperability is the ability of diverse systems to work together (interoperate).
Key Fob: An item attached to a key ring or key chain, used either for decoration or to assist the
owner in the act of authentication.
Microcontroller: A microprocessor that is optimized for self-sufficient systems, usually runs on
low power, and does not require a complex set of hardware.
Motion sensor: Sensor for detecting movement or motion. This sensor could use radio
frequency or changes in light to detect motion.
LabVIEW: Laboratory Virtual Instrumentation Engineering Workbench, platform and
development environment for a visual programming language created by National
Instruments. A graphical programming tool allowing for the display and acquisition of
data from a great deal of devices including external hardware.
Pressure sensor: Sensor for detecting change in pressure.
Proprietary Hardware: A device that is designed for specific purpose and lacks generic
qualities that would allow it to be used outside of its original implementation.
Pulse Oximeter: A medical device that is used to measure oxygen saturation in one’s
bloodstream. The arterial blood vessels expand and contract with each heart beat
changing the oxygen concentration which allows the device to measure pulse rate.
Radio Frequency (RF): Any frequency within the electromagnetic spectrum associated with
radio wave propagation. When an RF current is supplied to an antenna, an
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
10
electromagnetic field is created that then is able to propagate through space. Many
wireless technologies are based on RF field propagation.
Respiration: Breathing in order to bring oxygen to the bloodstream and remove carbon dioxide.
The act of respiration reduces the amount of oxygen and increases the amount of carbon
dioxide enriched.
Sensor: Any device designed to measure conditions or ambient pressures and temperatures. A
sensor is electronic in nature and designed to send a voltage signal to computer device.
Thermistor (Temperature sensor): A thermally sensitive resistor that produces a difference in
electrical resistance when a change in temperature occurs.
Universal Serial Bus (USB): USB is a serial bus standard to interface devices. USB is intended
by design to allow peripherals to be connected using a single standardized interface
socket and utilizing plug and play capabilities.
Virtual instrument (VI): Is an object that represents an instrument which contains the behaviors
for which the instrument produces. A VI can be designed using Labview software that
utilizes G code. By programming the input and output criteria as well as the logic of a
LabVIEW file a virtual instrument can be created.
(This Space Intentionally Left Blank)
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
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.
(This Space Intentionally Left Blank)
11
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
12
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 DFM system prototype will demonstrate the feasibility and the architecture of the
final design. The following will describe a few different aspects of the prototype. The
architecture description as well as an overview of the functional description will be focused on in
this section.
(This Space Intentionally Left Blank)
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
13
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 action would simulate a child sitting in a rear
or safety seat.
Microcontroller/CPU
LabVIEW simulation software will 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.
Bluetooth
Reciever/Transmitter
(Key Fob)
The same implementation will take place, but the transmitter will not be in the form of
a key fob, but rather a handheld Bluetooth enabled device.
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 Version 2, David Ballentine
14
2.2 Prototype Functional Description
The major functional components are described separately in Table 1. 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 Version 2, David Ballentine
15
The bottom path works with the key fob. If the key fob signal is weakened to a certain
point, it is 20 feet or more away from the vehicle. If this happens, the bottom path will be
triggered
The middle path is the Detect Life path. Both the top and bottom paths are dependant
upon this middle path. This means that life must always be present if the alarm is to sound. If
this path is triggered, either the bottom or the top path may be triggered for the alarm to sound.
The dotted box in this path is presented in 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 Version 2, David Ballentine
16
tripped, this value is assessed to the accumulated detection value. If this value is greater than
five, 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 algorithm runs through every sensor as well as the
alarm and if they are all validated, will set the system to working condition.
(This Space Intentionally Left Blank)
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
17
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. These interfaces include hardware, software, user, and communication
protocol interfaces.
2.3.1 Hardware Interfaces
The hardware interfaces in the DFM system include three things. The first is the key fob.
While this device cannot be directly interfaced, the user does control its location. If it is over 20
feet from the car, the device will activate. The second device is the switch to temporarily disable
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
18
the alarm. The third is starting the vehicle itself. This process will reset the DFM system. The
sensors themselves work automatically and should not be interfered with in the real world
product. As such, they are not considered as hardware interfaces.
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. A graph of each sensor’s output
is displayed along with the current value. The status of the overall system and the alarm is also
displayed.
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 samples for any of
the sensors provided. The algorithm will still act as though these readings were read in from the
sensors. This interface must be on an appropriate computer as specified in the requirements
under LabVIEW Setup.
2.3.4 Communication Protocols and Interfaces
This section is not necessary as there are no specific communication protocols in the
DFM system.
3
SPECIFIC REQUIREMENTS
The following information provides specific information about the prototype. Functional
requirements, performance requirements, assumptions and constraints, and non functional
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
19
requirements will all be covered in this section. This section is broken down into subcategories
for more precise details.
3.1 Functional Requirements
The functional requirements describe the capabilities of the DFM system prototype. They
describe what the product must do in order to meet the previously discussed goals and objectives
of the project. All graphical requirements are to be completed using the LabVIEW application.
The following requirements will ensure that the prototype effectively completes all performance
goals required to successfully represent the completed product.
3.1.1 DFM System Activation Process
The system activation process runs each time the vehicle is shut off. It checks each of the
sensors and prepares the DFM system to run the main algorithm. Once the system is activated,
the main algorithm [figure 3] will begin facilitating life detection. The procedures included in the
subsections below must occur for the DFM system to be activated.
3.1.1.1 Sensor Overview
Data is received from each of the sensors, which may use to evaluate its performance.
Each of the sensors is capable of operating independently from one another. All of the sensors
used in the prototype will comply with the following requirements.
1.) Each sensor must read in data independently.
2.) Each sensor will display this data to the screen in an easy-to-read view.
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
20
3.1.1.2 Life Detection Sensors
The Life Detection Sensors [figure 6] are the
sensors responsible for the detection of an occupant
inside the vehicle. These sensors work together, as
defined in the Life Detection Algorithm [figure 4].
The sensors will meet the following functional
requirements.
Figure 6. Life Detection Sensors.
1.) The Life Detection Sensors will return their assigned priority values or a value of zero. If
a sensor returns a value of zero, then it means no life is detected by this sensor; however, if a
sensor returns its assigned priority value, then it means life is detected by each sensor.
2.) The pulse sensor will determine pulse rhythm in the finger. It will not produce pulse
rhythmic data when it is attached to non-living things.
3.) The motion sensor will return a positive value when an object has a displacement of one
inch.
4.) The pressure sensor will increase the output value when pressure is applied; otherwise,
the reading should be at its initial stage.
5.) The microphone will determine any sounds in the environment; otherwise, the reading
should be at its initial stage.
6.) The simulated CO2 sensor will determine life using its predefined value.
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
21
3.1.1.3 Environmental Sensor
The Environmental Sensors [figure 7] are
responsible for determining the status of the
surrounding environment. These sensors will detect
if an occupant could be in danger. The sensors will
meet the following functional requirements.
Figure 7. Environmental Sensor.
1.) The temperature detector must detect the surrounding temperature within the accuracy
of 0.5 °F.
2.) If the temperature sensor records a temperature of less than 30 °F or more than 90 °F,
then the algorithm activates the DFM alarm system.
3.1.2 Life Detection Procedures
This process polls each of the sensors for positive values concerning life detection. If a
value returned indicates life then an accumulator has a specified value added to it [table 2]. The
life detection procedures will meet the following functional requirements.
1.) The DFM system will check each of the sensors for the appropriate values that indicate
life [figure 4].
2.) If the sensor has a value or change in data that indicates life, then the detection value
associated with that sensor should be added to the accumulation variable.
3.) If the accumulation variable has a value greater than five, then the life detection process
indicates a positive result.
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
22
4.) If the result of the life detection process is negative, then the process will run again with
entirely new data.
3.1.3 Environment Evaluation Procedures
The environmental evaluation procedures will evaluate if the conditions are unsafe based
upon the environmental sensors. The values determined by the environmental sensor will be
generated by a thermistor, also known as a temperature sensor. The procedures will meet the
following functional requirements.
1.) The temperature sensor will detect the temperature from inside of the vehicle.
2.) If the Life Detection Sensors detect life and the Environmental Sensors determine unsafe
conditions, then the DFM alarm system will be activated.
3.1.4 Transmitter and Receiver Functions
The receiver and transmitter will determine the driver's distance from the vehicle. Once
the driver is too far away the DFM system will assume that the child was forgotten and in serious
danger. Functionality involving the transmitter will be implemented with a Bluetooth enabled
device, while the receiver will be a Bluetooth adaptor connected to the laptop. The transmitter
and receiver will meet the following functional requirements.
1.) The transmitter will keep sending a signal to the receiver.
2.) The receiver will detect the transmitter within its perimeter range.
3.) The receiver will light up when the transmitter is detected.
3.1.5 Alarm System
The alarm will be implemented with a sound file played over the speakers of laptop the
DFM prototype is using. An alarm allows the DFM system to get the attention of the driver or
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
23
bystanders near the vehicle. By effectively alerting the public, the alarm system will facilitate
early action and communicate the overall severity of the situation to people nearby. The alarm
system will meet the following functional requirements.
1.) The DFM activation process has been completed and indicates the system is working.
2.) The state of the ignition is off.
3.) The reset switch is checked to determine if one has selected to preempt the alarm.
4.) The Environmental Sensor indicates an unsafe temperature value before the alarm system
can be activated.
5.) The life detection procedure runs. If the value received is greater than five, then an
occupant has been verified.
6.) The temperature must be extreme and an occupant must be detected before the alarm
system will activate.
7.) If the temperature is not extreme, the receiver must be out of range and an occupant must
be detected for the alarm system to activate.
8.) The alarm system is deactivated and the system is reset, if the reset switch is pressed.
9.) The system continues to check for extreme temperatures and occupants until the alarm
system is activated or the car is turned on.
3.1.6 Reset Procedures
The following details the procedures for resetting both the system and the alarm. The
reset falls under two categories reset and preemptive reset. The reset restarts the system and
allows the driver or emergency personnel to resolve the situation. Preemptive reset is used when
no immediate environmental danger is present, but the alarm may still go off. The reset
procedures will meet the following functional requirements.
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
24
1.) If the reset is pressed while occupancy is detected and temperature is high, the system
must not reset.
2.) If the reset is pressed and temperature is not high but an occupant is detected and the
transmitter is out of range, the system resets the algorithm and the alarm.
3.) The alarm must turn off when reset.
4.) If the reset is pressed with no current alarm sounding, the system is preemptively reset.
The alarm will not sound as long as the temperature is not dangerously high.
5.) When the car is simulated to turn on, the system is turned off. The system resets the
algorithm and the alarm.
3.1.7 LabVIEW Setup
The following details the procedures for setting up the LabVIEW software on a
compatible computer. The LabVIEW application software is required in the prototype. The
LabVIEW Setup will meet the following functional requirements.
1.) LabVIEW must be installed on a computer with a compatible operating system (Linux or
Windows), with an available USB port.
2.) LabVIEW must be fully updated.
3.) Drivers for the DAQ must be installed.
4.) DAQ must be plugged into the USB port on the computer.
5.) Appropriate prototype sensors must be plugged into the DAQ.
6.) The Prototype VI file must be running.
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
25
3.1.8 Simulation Procedures
The simulation procedures are requirements for the simulation of data instead of using
the sensor’s input. Simulated sensors are necessary to fulfill the purpose of a real sensor in the
prototype without adding unnecessary complexity or cost to the system. The simulation
procedures will meet the following functional requirements.
1.) Data files must be proper format.
2.) Simulated values must be in appropriate range.
3.) LabVIEW must correctly wire into data files.
3.2 Performance Requirements
The following performance requirements describe how well the aforementioned
procedures work in quantifiable terms. All graphical requirements are to be completed using the
LabVIEW application. The following performance requirements directly relate the procedures
explained in the previous section.
3.2.1 DFM System Activation
The activation process tests each of the components in the DFM system to ensure that
errors are found before the system is relied on to save lives. As the system is activated, the
system will test if it is working properly. The system activation will meet the following
performance requirements.
1.) Each sensor will send a signal to LabVIEW.
2.) Each sensor’s value will be greater than or equal to its rated minimum value.
3.) Each sensor’s value will be less than or equal to its rated maximum value.
4.) Each sensor will return a value within 10 seconds.
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
26
5.) The entire activation will take no more than 60 seconds.
3.2.2 Life Detection
The process of life detection uses the array of sensors to determine their combined
outputs that could indicate life. Each sensor contributes to the accuracy of the system.
Therefore, each sensor much be tested to ensure that it does not provide false data to the Life
Detection Algorithm. The life detection procedures will meet the following performance
requirements.
3.2.2.1 Sensor Performance
Each of the sensors used in the DFM system have very different types of data. The data
that it gives as output is specifically related to the medium the sensor is evaluating. Sensor
performance will be evaluated on the following criteria.
1.) The pressure sensor will be capable of determining pressure of at least one PSI.
2.) The motion sensor will be capable of determining vibration of more than 40dB.
3.) The pulse oximeter will be capable of determining finger pulse of 60-150bpm (beats per
minute).
4.) The microphone will be capable of determining sound of more than 10 dB.
3.2.2.2 Procedure Performance
Each of the sensors used in the DFM system have very different types of data. The data
that is sent by each sensor is directly correlated to its specific function. Sensor performance will
be evaluated on the following criteria.
1.) Each sensor’s value will be greater than or equal to its rated minimum value.
2.) Each sensor’s value will be less than or equal to its rated maximum value.
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
27
3.) Each sensor will return a value in less than one second.
4.) The entire procedure will take no more than nine seconds.
5.) Transmitter will send signal to receiver if occupancy is detected.
3.2.3 Environmental
This section describes the DFM system’s sole environmental sensor, the temperature
sensor. The sensor performance subsection describes the performance of the temperature device
alone. The temperature sensor is attached to the DAQ device connected to the laptop through
USB port. The next subsection, which is the procedure performance, describes the performance
of the temperature sensor in related to the life detection algorithm of the DFM system.
3.2.3.1 Sensor Performance
This section describes the performance of the DFM system’s environmental sensor. The
temperature sensor is the sole environmental sensor of the DFM system. The temperature sensor
device will meet the following performance requirements.
1.) The temperature sensor is capable of reaching between the temperatures of 30 °F and 90
°F, inclusive.
2.) The DFM system will update the current temperature reading within less than 10
seconds.
3.) The temperature sensor’s value will be greater than or equal to its rated minimum value.
4.) The temperature sensor’s value will be less than or equal to its rated maximum value.
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
28
3.2.3.2 Procedure Performance
This section describes the procedure of the DFM system’s environmental sensor. The
temperature reading is essential, as it is part of the Life Detection Algorithm. The procedure for
temperature reading will meet the following performance requirements.
1.) Must return a true value to the life detection algorithm if temperature reading is 30 °F or
below or 90 °F or above.
2.) Must return a false value to the life detection algorithm if temperature reading is above
30 °F and below 90 °F.
3.) Must keep sending the current reading to the life detection algorithm within less than 10
seconds.
3.2.4 Transmitter and Receiver Functions
This section covers the performance of the DFM system’s transmitter and receiver. The
DFM system will use two Bluetooth communication devices for sending and receiving signals.
The light indicator on the DFM system’s GUI will light up steadily when the transmitter is
within the range of the receiver. The transmitter and receiver will meet the following
performance requirements.
1.) The transmitter must be capable of sending a signal once every 10 seconds.
2.) The receiver must be capable of detecting the transmitter within 20 feet. Light indicator
will be off when transmitter is beyond 20 feet.
3.) The receiver updates reading every 20 seconds or less.
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
29
3.3 Assumptions and Constraints
Given the limitations of the prototype the following assertions must be made to ensure
that the prototype has the functionality necessary to accurately emulate the fully implemented
version. In Table # is a list of assumptions, constraints, and dependencies for the prototype.
Each element in the list was added to facilitate a successful demonstration of the prototype.
Condition
Type
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. Features Comparison Table.
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
30
3.3.1 Assumptions
Since the DFM system uses several sensors to evaluate the environment in the vehicle the
sensors must be able to detect an environment that would be similar to the environment of a
potentially dangerous vehicle. Therefore, the first two assumptions are that a device will be
present at the demonstration that will force the temperature sensor to read values above 90° F
and below 30° F. Since the room temperature cannot be changed so dramatically in a short
period of time, a device will be needed to facilitate the change in temperature. Next, the pressure
sensor, unlike the one implemented in the commercial version, will not be responsible for
detecting the variations in pressure from one moment to the next. Instead, the pressure sensor
will test whether or not there is force against it and indicate that it detects a person accordingly.
The following two assumptions deal with the occupant and their possible health and
behavioral deviations from a typical passenger of the same age. Given that special calibrations
may be needed for occupants with health problems, it is assumed that the occupant has no
remarkable medical conditions. Therefore, any special calibrations for passengers with health
concerns will not be dealt with in the prototype. Secondly, since one’s clothing could exacerbate
the situation by prematurely over heating or over cooling him or her, it is assumed that the
occupant is appropriately dressed for the weather. The assumptions involving health and
clothing are needed so the system does not need to be changed in the event that the occupant in is
danger far before the extreme temperatures are reached.
Lastly, while the reset switch is designed to prevent any accidental or intentional harm, it
is assumed that it will not be used maliciously. Given that the alarm can not be shut off while
life is detected and the temperature is high or low, it is unlikely one could manipulate the reset
switch to cause harm to an occupant. However, since the switch is to be used with the
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
31
understanding that the occupant is capable of leaving the vehicle at any time before the
temperature becomes extreme; the driver can use it to leave an occupant in the car momentarily.
Although, the alarm will still go off when the environment becomes dangerous it may still result
in the occupant being in the vehicle too long. This scenario indicates that the driver understands
their actions and manipulates the system to separate their self from the vehicle before the alarm
is set. Therefore, the last assumption is that the driver will not attempt to circumvent the safety
features of the vehicle in order to deliberately harm an occupant of the vehicle.
3.3.2 Constraints
In order to develop the DFM system prototype in a timely manner some of the features to
be implemented in the final version had to be reduced. First, the CO2 sensor, unlike the other
sensors used in the prototype, will not be physically implemented. Instead, reading from the
sensor will be from a table of previously generated values. By generating the values rather than
implementing the actual sensor the prototype can be constructed with less effort and cost.
Likewise, all of the other sensor will have their output data stored in a table to ensure that the
DFM system prototype will be functional despite any hardware malfunctions.
Secondly, the pulse oximeter differs greatly from the accelerometer in that it measures
the pulse analytically rather than directly. An accelerometer can be implemented so that it can
detect the vibrations of ones heartbeat and analyze the vibrations to determine a pattern. The
pulse oximeter does not actually measure one’s pulse; instead it measures the intensity of the
infrared light after it passes through a human’s finger. The reason infrared light is measured is
because the intensity varies with the amount of oxygen in the medium it is traveling through. In
other words infrared light travels through oxygen rich blood better than oxygen deficient blood.
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
32
As the heart beats it supplies the body with oxygen rich body and changing the way infrared light
passes through one’s finger. The variations in the oxygen levels of a person’s blood are directly
correlated their heart beats. Therefore, the infrared light can be used to measure a heart beat. By
using the pulse oximeter instead of an accelerometer the prototype in constrained by the fact the
occupant must attach the pulse oximeter to their finger, which would be very inconvenient in the
final product.
Lastly, the final product will be able to determine when the car’s temperature will
become dangerous by analyzing the change in temperature over time. The prototype is not
capable of determining the temperature change; rather, it assesses the temperature’s current value
alone. While the final product will be able to preemptively set off the alarm if it detect that the
car will become dangerous in a matter of minutes, the prototype will set off the alarm only when
danger is eminent.
3.3.3 Dependencies
The two dependencies for the prototype are both based on the method in which it is being
implemented. First the hardware will function properly at the time of demonstration. It may be
possible to conduct the demonstration using only virtual sensors; however, the prototype would
lose all credibility if it’s most innovative aspect, the array of sensors, did not even function.
Therefore, in order to have a successful demonstration it is imperative that all sensors it is
designed to run with are fully functional.
Secondly, the software that is being used to write the logic for the DFM system and
integrate the sensors will not only be installed but working for the demonstration. Given that
every aspect of the prototype interacts through the LabVIEW software and the data acquisition
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
33
device. It is of the highest level of importance that is software can run throughout the
demonstration.
3.4 Non-Functional Requirements
The non-functional requirements are the aspects of the prototype that are outside the core
innovative functionality of the system. They are security, maintainability, and reliability. Each
of these aspects are important to the success of the product.
3.4.1 Security
The security of the DFM system and the vehicle are issues of little concern. In the event
that the integrity of the product is compromised no harm can come to the user financial, or
physically. The DFM system does not store any information about the passengers of the vehicle
or any long-term records.
The DFM system has no control over the vehicle other than the horn and therefore cannot
be manipulated to achieve entry into the vehicle. Any attempt to break into the vehicle while the
DFM system is activated would likely result in the alarm being activated unless the individual
also had the key fob device on their person. Under no circumstances does the DFM system
compromise the security of the owner’s car, or personal information.
3.4.2 Maintainability
In the event that the activation sequence indicates that one or more aspects of the DFM
system are not fully functional a warning light will be lit on the driver’s warning panel. The
DFM system will continue to run without the specific component until it can be examined by a
professional. If it is determined the DFM system is impaired to the point where it cannot
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
34
function in a successful manner the system will be completely disabled to prevent false alarms.
Since the automobile manufacturer has liberty over the specific implementation of the system, it
is their responsibility to integrate the system into their set of diagnostic tools. The DFM system
will provide the necessary outputs to be integrated into the diagnostic kit the manufacturer
designs.
3.4.3 Reliability
The DFM system must run continuously when the vehicle is not on to ensure that no life
is present inside at any time. Likewise, the DFM system must go through the activation
sequence every hour to ensure that all sensors are performing accurately. Since the system is
autonomous, there will be few instances when the driver must actually interact with the system.
Therefore, it the responsibility of the system to work without the driver’s effort and to
consistently check that the data it is analyzing is accurate.
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
4
35
APPENDIX
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 DFM System:
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
Linear 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
779320USB-6008 Kit (LabVIEW and DAQ)
22
Company
Qty Price Ea Total
Jameco.com
2
$7.95
$15.90
Jameco.com
2
$8.99
$19.98
Jameco.com
2 $24.95
$49.90
Omega.com
1 $61.00
$68.00
FitnessEquipment
2
$19.99
$39.98
NI.com
2
$159.00
$331.62
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
Total
$37.00
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.
$37.00
Lab 2 – DFM Prototype Product Specifications Version 2, David Ballentine
b. LabVIEW must have the drivers installed for the DAQ used in the
prototype, a USB-6008.
c. Quantity 1
d. Date required: March 1, 2008
e. Deliver to: Don’t Forget Me Inc.
36