Lab 1 – DFM Product Description Version 2, David Ballentine
Lab 1 – DFM Product Description Version 2
David Ballentine
CS411
Janet Brunelle
February 27, 2007
1
Lab 1 – DFM Product Description Version 2, David Ballentine
2
TABLE OF CONTENTS
1
INTRODUCTION ................................................................................................................ 3
2
DFM PRODUCT DESCRIPTION ...................................................................................... 4
2.1
2.2
2.3
3
DFM PRODUCT PROTOTYPE DESCRIPTION ............................................................ 9
3.1
3.2
3.3
3.4
4
KEY PRODUCT FEATURES AND CAPABILITIES .................................................................. 5
MAJOR COMPONENTS (HARDWARE/SOFTWARE) ............................................................. 6
TARGET MARKET/CUSTOMER BASE ................................................................................. 9
PROTOTYPE FUNCTIONAL OBJECTIVES .......................................................................... 10
PROTOTYPE ARCHITECTURE (HARDWARE/SOFTWARE) ................................................. 11
INNOVATIVE FEATURES (OF PROTOTYPE) ....................................................................... 14
CHALLENGES AND RISKS ............................................................................................... 14
PROTOTYPE DEMONSTRATION DESCRIPTION.................................................... 15
GLOSSARY ................................................................................................................................ 16
REFERENCES............................................................................................................................ 17
LIST OF FIGURES
FIGURE 1. KIDS AND CARS CHILDREN FATALITY DIAGRAM (KIDS AND CARS, 2007)...................... 4
FIGURE 2. COMPETITION MATRIX, FINAL AND PROTOTYPE. ............................................................ 6
FIGURE 3. MAJOR FUNCTIONAL COMPONENT DIAGRAM.................................................................. 7
FIGURE 4. PROTOTYPE MAJOR FUNCTIONAL COMPONENT DIAGRAM. ........................................... 10
LIST OF TABLES
TABLE 1. FEATURES COMPARISON TABLE ..................................................................................... 13
Lab 1 – DFM Product Description Version 2, David Ballentine
3
1 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.
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.
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 1 – DFM Product Description Version 2, David Ballentine
4
addressed with the Don’t Forget Me system (DFM system) by utilizing a system of sensors,
alarms, and algorithms.
Figure 1. Kids and Cars Children Fatality Diagram (Kids and Cars, 2007)
2 DFM PRODUCT DESCRIPTION
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
vehicle by measuring the signal strength of a transmitter on the vehicle key.
Lab 1 – DFM Product Description Version 2, David Ballentine
5
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.
2.1 Key Product Features and Capabilities
The key features of the DFM system include the design of using a broad range of sensor
technology, as well as building the system into the vehicle directly. Other similar products are
incorporated instead into a specialized child car seat. This approach has the inherent flaw in that
it has to be purchased specifically by the customer. A typical parent will not admit to any
possibility of this happening and thus will not buy the specialized car seat. Since the DFM
system is incorporated into the vehicle during manufacture, it will simply be an included
protection much like standard air bags. Its operation will be transparent to the user until there is
a problem.
Since similar products build the system into a car seat, certain assumptions about the
baby actually being in the seat are made. Since the DFM system cannot make these assumptions,
it must use a broad arrangement of sensor technology to determine if there is an occupant in the
vehicle, the environmental condition inside the vehicle, and what response to take. Figure 2
shows how the DFM components differ from these other similar products. These features make
it a unique and superior system for saving lives.
Lab 1 – DFM Product Description Version 2, David Ballentine
Figure 2. Competition Matrix, Final and Prototype.
2.2 Major Components (Hardware/Software)
Most of the components used by the DFM system are sensors. There are also the
transmitter device and the car alarm. Figure 3 shows the setup of the components.
6
Lab 1 – DFM Product Description Version 2, David Ballentine
7
Figure 3. Major Functional Component Diagram.
Every sensor needed for the DFM system serves a specific purpose. The pressure sensor,
accelerometer sensor, motion sensor, CO2 sensor, and microphone all serve to determine if there
is an occupant in the seat by using a weighted algorithm on the readings of these sensors. All
five of the sensors are needed since an individual sensor could be fooled. A backpack, for
example, could trigger the pressure sensor. The temperature sensor determines the condition
inside the vehicle. Temperatures above or below a certain point are considered dangerous and
Lab 1 – DFM Product Description Version 2, David Ballentine
8
will trigger the alarm if it is determined there is an occupant present using the other sensors
described earlier.
The transmitter device will be inside of the vehicle’s key. The remote detector will pick
this up. When the signal degrades to a certain point, there is more than a twenty-foot distance
between the transmitter and detector. At this point, if there is an occupant inside the vehicle, the
car alarm will sound. The reset switch will temporarily disable the alarm; it is located on the seat
the occupant is on. Once flipped, the system will switch to standby mode until the conditions
become too harsh.
Although the DFM system utilizes all of these components, none are included with the
DFM system. The software algorithm, as well as a list of needed and compatible devices, will be
included however, the car manufacture will be responsible for the actual integration of the
devices in each separate make of vehicle. The reason for this arrangement is that every car
model is different. It would be impossible to provide specific sensors that would satisfy the
requirements for every model. Also, each manufacturer has its specific way of doing things and
wiring components. The DFM system has to be seamlessly integrated which is why it is up to
the manufacturers.
The DFM system software will be able to analyze the sensors hooked up to it and make
the actual predictions. This prediction algorithm is the core of the DFM system and what is
actually being marketed. This is the reason there are five different sensors. Each sensor will
have a different accuracy rating which will determine its priority in the algorithm. The algorithm
must be precise enough to avoid false alarms, yet never fail to alarm if there is a real threat.
Lab 1 – DFM Product Description Version 2, David Ballentine
9
2.3 Target market/Customer Base
The target customer of the DFM system is car manufacturers. The system is to be
installed directly into the vehicle during the vehicle’s manufacture. The manufacturer will
purchase the DFM system software for a vehicle model, and a license to use it for every vehicle
it is installed into. Because the manufacturer will be purchasing the actual sensors separately,
they will be able to select supported sensors that will best fit into the specific vehicle model.
The secondary costumer is the end user. While the DFM system will not be marketed
directly to the end user, this user must still be considered in the creation of the DFM product. If
something goes wrong with the system, this end user will be the one to complain to the
manufacturer. The DFM system must work transparently to the end user until a situation
requiring the device will sound the alarm.
3 DFM PRODUCT PROTOTYPE DESCRIPTION
The prototype of the DFM system will encompass almost everything that will be on the
final product, except on a smaller scale. Figure 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..
Lab 1 – DFM Product Description Version 2, David Ballentine
10
Figure 4. Prototype Major Functional Component Diagram.
3.1 Prototype Functional Objectives
The first objective of this prototype is to demonstrate that the sensors will work as
planned. These sensors have never before been put into this arrangement to work in this
situation. The foundation of the theory is sound, but certain complications only arise when
tested. The prototype will serve as that test bed for these sensors. Except for the CO2 sensor, all
Lab 1 – DFM Product Description Version 2, David Ballentine
11
of the sensors are actual working examples similar to what will go into the actual product. The
prototype will also prove that the idea is sound and production should go forth.
The second objective of the prototype is to provide a tool to work out some of the
specific algorithms.
These algorithms must be very accurate, and there is no way to simulate
some of the situations without an actual live experiment. The algorithm will weigh out the
results of the sensors an come to a conclusion. The prototype will provide a way to scrutinize
these algorithms until they are as accurate as possible using the sensors involved.
The third objective is to root out any major design flaws. It may be that another sensor
must be placed into the scheme for the system to work, or the transmitter for the key is not strong
enough to broadcast over twenty feet. The prototype will determine these factors among others.
The final product will be greatly influenced by what works well and what does not during the
prototype.
The fourth and final objective of the prototype is a marketing basis. The prototype can be
used to sell the DFM system to a manufacturer. Without it, the manufacture will have no real
world example of how the system is supposed to work and how it should be implemented into
their vehicles. The prototype will demonstrate a variety of scenarios and show the results of
each one.
3.2 Prototype Architecture (Hardware/Software)
The prototype will utilize the same types of sensors and setup as the final version. These
will be simpler counterparts; however, they will be compared to the ones that will be used in the
final product. Table 1 shows the comparison of the prototype components with those of the final
version.
Lab 1 – DFM Product Description Version 2, David Ballentine
12
Features Comparison Table
Features
Real-World
Prototype
Heartbeat Sensing
An accelerometer will be installed
that is capable of sensing a
heartbeat through the vehicles back
seat. The accelerometer can detect
small fluctuations in movement,
thereby indicating a heart rhythm.
It will also be used to monitor
health based on rhythm.
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
The sensor will measure the level
of CO2 in the vehicle. A steady
No CO2 sensor will be used for the
increase will indicate there is no
prototype, rather the sensor will be
ventilation and human or animal is simulated in LabVIEW.
present.
The temperature sensor will read in
very precise values to determine
Temperature Sensor the rate of temperature change to
determine when a threat may
become imminent.
A temperature sensor will read the
current temperature of the room
and indicate when the level
becomes too dangerous for a
human.
Motion Sensor
The software will analyze the
values read from the motion sensor
over time to determine if the
readings may be influenced by a
person. An instance of motion
without life would be the
movement of the vehicle’s air
conditioning vents.
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
Like the motion sensor, the values
given to the software will be used
to determine if there is not a pattern
that could indicate life. This would
mitigate false alarms due to devices
that could trigger the sensor, such
as a child’s mechanical toy.
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.
A microcontroller will be used to
implement the software created by
the DFM development team. The
Microcontroller/CPU controller will interface with all the
hardware and run the analysis
algorithms to evaluate the state of
possible passengers.
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
Lab 1 – DFM Product Description Version 2, David Ballentine
13
an input/output device known as a
DAQ.
Reset Switch
A switch will be placed in rear of
the vehicle so that the driver can
manually shut off the device in
case of a false alarm. The switch
will time out if the system still
indicates danger and when the car
is restarted.
A switch will be added to the set
of hardware, but the logical
implementation will not be as
elaborate.
A receiver will be placed in the car
with the generator as a key fob.
The same implementation will
Infrared
When the generator goes out of
take place, but the generator will
Reciever/Transmitter
range (20ft.), the car’s alarm will
not be in the form of a key fob.
sound.
Alarm
The alarm will be implemented by
whatever means the car
manufacturer would like. It is
strongly suggested that the car’s
built in horn or alarm system be
used given the public’s familiarity
to car alarms and what they entail.
A small speaker will be used to
generate noise and indicate the
alarm. A car alarm will not be
necessary to demonstrate.
Microphone
A simple microphone will be
integrated into the DFM system at
the middle rear section of the
vehicle behind the seat. The
microphone will merely check the
intensity of noise in the vehicle. In
the event that the noise is above a
predefined decibel level the
microphone will indicate life.
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
The software in the prototype includes the software with the algorithms that will be in the
final product, as well as a GUI display. The GUI display will show the status of the current
sensors. All of the sensors will be in working condition; however, for testing and demonstration
purposes, these values can also be overridden. An example would be changing the temperature
Lab 1 – DFM Product Description Version 2, David Ballentine
14
inside the car and watching the results of this action. This part of the prototype will be using a
program called LabVIEW to process both the sensor and simulated datasets.
3.3 Innovative features (of prototype)
This prototype demonstrates that the DFM product is feasible and actually works. As
mentioned in this document, the DFM system employs a unique arrangement of sensors to work
for a specific goal. The prototype will show that this arrangement is the best for what is trying to
be accomplished.
The GUI of the prototype will also demonstrate exactly what is going on at a low end
level. The exact state of the program can be witnessed in real time. The user will be able to
manipulate the program and simulate any and all potential situations. The strength of designing
the prototype in this way is real-time assessment of whether the software algorithms are working
correctly or not.
3.4 Challenges and Risks
The major challenge of this prototype is to get the algorithms to work exactly as planned.
There is little room for error when creating the final product, since human life is on the line. The
system must show that the sensors work and that this is a viable solution. Another major
challenge is to acquire the needed sensors in the amount of time and money allotted.
A major risk of this prototype is to not show enough of the end product. If a close
enough example of the DFM system is not shown, no one will be convinced that the DFM
system can work. In this case, the prototype will be a failure. There is also the risk of showing
too much and thus making every one expect more from the end product. A balance between the
two risks must be met for a successful prototype.
Lab 1 – DFM Product Description Version 2, David Ballentine
4 PROTOTYPE DEMONSTRATION DESCRIPTION
The prototype demonstration will take place at the beginning of May, 2008 in the ODU
Computer Science conference room. In a mach-up scenario, each of the sensors will be
demonstrated in both its functionality and purpose in the overall design. After this, several
simulations will be made overriding the actual sensors to show results under different datasets.
LabVIEW will be used as the GUI screen to demonstrate the scenarios in real time. The floor
will also be open for any audience members to recommend any input value into the program to
observe what will happen.
15
Lab 1 – DFM Product Description Version 2, David Ballentine
16
GLOSSARY
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.
Lab 1 – DFM Product Description Version 2, David Ballentine
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.
17