Lab 2 – Don’t Forget Me: Product Description
Brandon Fields
CS411
Janet Brunelle
March 5, 2008
Lab 2 – Don’t Forget Me
Table of Contents
1
Introduction ................................................................................................................. 1
1.1
Purpose................................................................................................................ 2
1.2
Scope ................................................................................................................... 4
1.3
Definitions, Acronyms, and Abbreviations ........................................................ 5
1.4
References ........................................................................................................... 7
1.5
Overview ............................................................................................................. 7
2 General Description .................................................................................................... 7
2.1
Prototype Architecture Description .................................................................... 9
2.2
Prototype Functional Description ..................................................................... 12
2.3
External Interfaces ............................................................................................ 16
3 Specific Requirements .............................................................................................. 19
3.1
Functional Requirements .................................................................................. 19
3.2
Performance Requirements ............................................................................... 21
3.3
Assumptions and Constraints ............................................................................ 22
3.4
Non-Functional Requirements .......................................................................... 26
4 Appendix ................................................................................................................... 27
4.1
Formal Resource Request Document................................................................ 28
List of Figures
Figure 1.
Figure 2.
Figure 3.
Figure 4.
Figure 5.
Figure 6.
Figure 7.
Major functional component diagram ................................................................ 2
Phase 1 prototype major functional component diagram................................... 9
DFM Algorithm Flowchart ............................................................................. 12
DFM Activation Flowchart ............................................................................. 14
DFM Life Detection Algorithm ...................................................................... 15
Alarm VI Front Panel display .......................................................................... 17
Alarm VI Block Diagram ................................................................................. 18
List of Tables
Table 1. Sensor priorities .................................................................................................... 3
Table 2. Feature comparison between full product and prototype.................................... 11
Table 3. Effects of Assumptions, Dependencies, and Constraints on Requirements ....... 23
i
i
Lab 2 – Don’t Forget Me
1 Introduction
Last year at least 43 children died in cars while their parent or caregiver was away, and
each year the number of deaths increases (KAC, 2007). Unfortunately, it does not take long for a
car to become dangerously hot and endanger the life of a child inside. As of now, modern cars
do not have the capability to determine when the conditions of its interior could pose a danger to
its passengers, nor do many vehicles have the ability to register that a child has been left inside.
The goal of the Don't Forget Me (DFM) system is to eliminate such instances of
unintentional child endangerment. By implementing a series of sensors that determine if a
vehicle is occupied, the system can immediately take corrective action. A heartbeat sensing
system is one of the primary components; the data it collects is analyzed for a verifiable pattern.
Secondly, pressure sensors installed beneath the seats determine if anyone is occupying the
vehicle. Once again, the outputs of the sensors are checked by the accompanying software to
ensure it is a person and not an obstruction that is detected. A microphone is implemented to
monitor for loud noises which will help determine if the vehicle is occupied. Temperature,
motion, and CO2 are also constantly monitored inside the car. Since the temperature can rise to
fatal levels in minutes, a high temperature reading initiates an aggressive check of the vehicle for
persons who may be in danger.
When inputs from all the sensors collectively indicate that the vehicle is occupied, the
vehicles alarm system is initiated. Also, the driver’s key fob attachment will begin to vibrate to
indicate that the alarm system has been activated. This device is autonomous and does not
require the activation of the car's operator. It seeks to eliminate instances when one can let even
important issues pass their attention (Fields, 2008).
1
Lab 2 – Don’t Forget Me
1.1 Purpose
The DFM safety system is unique because it utilizes an assortment of sensors to detect
life in a manner that has never before been implemented. While two or more sensors may be
sufficient to detect life, more would be necessary to reach a high degree of certainty. Each
sensor allows the software to incorporate a system of checks and balances to prevent false alarms
or decisions made from insufficient data. Likewise, the system will not be rendered useless
when one sensor inevitably malfunctions (given the lifespan of any component in a vehicle over
an extended period of time).
Figure 1. Major functional component diagram
2
Lab 2 – Don’t Forget Me
Overall, the greatest strength of the DFM system is the software developed to integrate
each hardware component into one homogenous system. Under the assumption that no two
types of sensors have the same accuracy, neither will they have the same priority. While a
motion sensor is effective at detecting movement, it would not have the same accuracy as a
heartbeat sensor meant to analyze a heart’s rhythm; therefore it is prudent to grant a positive
reading from the heartbeat sensor higher priority than the result from a motion sensor. A CO2
sensor is even less indicative of life given that the car is not airtight and the sensor may have a
low level of precision. As a result, the DFM system must take each of the sensor’s results into a
priority based system where each sensor is capable of generating a positive result for life
detection independently of the others.
Sensor Priority Value
Pulse Sensor
4
Motion Sensor
3
CO2 Sensor
3
Pressure Sensor
2
Microphone
1
Table 1. Sensor priorities
Table 1 indicates the specific priorities for the DFM system. In order for life to be
detected with a high level of certainty the sum of the values must be greater than five. The
specific values were designated based on the combination of sensor that would be needed to give
a positive reading for the alarm to be initiated. For example, the pulse sensor and any of the
three beneath it in the table will cause the alarm to go off. Likewise, the CO2 and the pressure
3
Lab 2 – Don’t Forget Me
sensor would not be high enough in priority to initiate the alarm, but if the microphone was also
getting a positive reading the system acknowledge the presence of life.
The process of prioritizing the sensor’s results allows the DFM system to correctly
indicate the presence of life even if some of the sensors are generating false results. In the same
manner that shareholders have proportional control of a company, each sensor will have a degree
of influence over the system, which is determined by its accuracy. The software will take into
account the different values of influence and certainty generated by sensor data and make an
educated decision whether to act (Fields, 2008).
1.2 Scope
The objectives of the prototype are to show that the DFM can in fact determine if a
human is present, it the environment will become hazardous, and if the driver is close enough to
provide assistance. The sensors can test if a human is present by providing data to the LabVIEW
(Laboratory Virtual Instrumentation Engineering Workbench) software where each sensor can
independently evaluate the vehicle. If the certainty is high over the majority of the sensors then a
person will be assumed present. This can be test buy setting off each sensor alone or in different
combinations to determine if the algorithm is affective.
Next, the environment is deemed hazardous if the temperature is rising or falling at a rate
that would become harmful. Not only is the current temperature taken into account, but also the
past temperatures. This way the DFM can set off the alarm even if danger is still minutes away.
The system would be very ineffective if it sounds an alarm only when the environment is deadly,
or even if the driver is too far gone to ameliorate the situation.
4
Lab 2 – Don’t Forget Me
Lastly, the prototype shows that a driver’s distance from the car is being monitored by the
DFM system. If the driver goes further than 20ft from the car to alarm will sound regardless of
the temperature in the car. Likewise, despite the driver’s distance from the car, the alarm will
sound if the temperature reached a fatal level. What is most important is any person or child left
in the car when the alarm sounds is removed before the system is reset, which is why the reset is
positioned in the rear center of the vehicle (Fields, 2008)
1.3 Definitions, Acronyms, and Abbreviations
Accelerometer – A device that measures the force on a sensor. 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.
CPU – Central Processing Unit, the device inside of a computer that executes machine code
(runs programs).
DAQ – Data acquisition, device that is used to send data to a computer using an external
interface, usually connected to proprietary hardware.
5
Lab 2 – Don’t Forget Me
DFM – Don’t Forget Me, a system designed to prevent harm to humans and animals by
detecting life and high temperatures in a vehicle.
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.
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.
LabVIEW – Laboratory Virtual Instrumentation Engineering Workbench, platform and
development environment for a visual programming language created by National
Instruments.
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.
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.
VI – A Virtual Instrument is a file in the LabVIEW software that abstractly represents a physical
instrument. By programming the input and output criteria as well as the logic of a
LabVIEW file a virtual instrument can be created.
6
Lab 2 – Don’t Forget Me
1.4 References
Fields, Brandon. (2008). Lab 1 – DFM Product Description. Norfolk, VA: Author.
Kids and Cars. (n.d.). Kids and Cars. Retrieved January 28, 2007, from Kids and Cars Web site:
http://www.kidsandcars.org/
Oximity. (2002). Principles of Pulse Oximetry Technology. Retrieved January 21, 2007, from
Internet World Stats Web site: http://www.oximetry.org/pulseox/principles.htm
1.5 Overview
This product specification provides details concerning the hardware and software design,
external interfaces, capabilities and features of the DFM system prototype. The following
information describes the implementation of the prototype as well as aspects of its design and
considerations made during testing and demonstration.
2 General Description
The DFM system is innovative in its use of simple sensors and the integration of
microcontroller technology in order to add a greater level of safety to modern automobiles. The
greatest strength of the DFM system is the algorithm that weights each of sensors in order to
7
Lab 2 – Don’t Forget Me
determine the likelihood of life and danger. The system intelligently decides when to act and
when danger is not present. Most importantly it seldom requires any direct interaction with the
driver.
8
Lab 2 – Don’t Forget Me
2.1 Prototype Architecture Description
The physical architecture of the prototype is focused around the LabVIEW simulation
software. LabVIEW makes it possible to interact with an array of sensors by wiring them into
the data acquisition device (DAQ). Once properly wired, the LabVIEW software can be used
interact with the ports on the DAQ. Therefore, the LabVIEW software and the laptop take the
place of the CPU. This removes the difficult task of creating the physical implementation of the
DFM system from their constituent components alone. Likewise, the algorithm can be
programmed and tested without wasting time and money programming into a microcontroller.
Figure 2. Phase 1 prototype major functional component diagram
9
Lab 2 – Don’t Forget Me
Figure 2 illustrates the major functional components of the DFM system prototype and
the interaction of its components. Table 1 elaborates on the reductions that will take place in
order to complete the prototype. Unlike the real-world implementation of the DFM system, there
will be no microcontroller for the system to be installed on; rather, all of the software will be run
through LabVIEW. While the microcontroller would allow the DFM system to run without a
dedicated computer, it would not be flexible enough to create a very low scale prototype.
Likewise, using a microcontroller rather than simulation software would make it more difficult to
test each component in the DFM system.
Features
Heartbeat Sensing
Real World Project
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.
Prototype
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 No CO2 sensor will be used for the
in the vehicle. A steady increase will
prototype; rather, the sensor will be
indicate there is no ventilation and
simulated in LabVIEW.
human or animal is present.
Temperature Sensor The temperature sensor will read in very A temperature sensor will read the
precise values to determine the rate of
current temperature of the room
temperature change to determine when a and indicate when the level
threat may become imminent.
becomes too dangerous for a
human.
Motion Sensor
The software will analyze the values read The motion sensor will read in
from the motion sensor over time to
several values over a short time
determine if the readings may be
period. If motion is detected over
influenced by a person. An instance of that time period, then the software
motion without life would be the
will assert that a person is present.
movement of the vehicle’s air
conditioning vents.
10
Lab 2 – Don’t Forget Me
Features
Pressure Sensor
Real World Project
Prototype
Like the motion sensor the values given The sensor will be placed under a
to the software will be used to determine cushion for the volunteer to sit on.
if there is not a pattern that could indicate By sitting he or she will activate
life. This would mitigate false alarms
the pressure sensor. This would
due to devices that could trigger the
simulate a child sitting in a rear or
sensor, such as a child’s mechanical toy. safety seat.
Microcontroller/CPU A microcontroller will be used to
implement the software created by the
DFM development team. The controller
will interface with all the hardware and
run the analysis algorithms to evaluate
the state of possible passengers.
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.
Radio Frequency
A receiver will be placed in the car with
Reciever/Generator the generator as a key fob. When the
generator goes out of range (20ft.), the
car’s alarm will 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.
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.
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.
A switch will be added to the set of
hardware, but the logical
implementation will not be as
elaborate.
The same implementation will take
place, but the generator will not be
in the form of a key fob.
A small speaker will be used to
generate noise and indicate the
alarm. A car alarm will not be
necessary to demonstrate.
The computer's microphone will be
used in LabVIEW to determine if
the decibel level has reached a
predefined level.
Table 2. Feature comparison between full product and prototype
11
Lab 2 – Don’t Forget Me
2.2 Prototype Functional Description
The prototype will be implemented with the USB-6008 Data Acquisition (DAQ) device
and the LabVIEW software. The DAQ will make it possible to attach several sensors to a laptop
and pass their input values to an application. The LabVIEW software will take the values from
the sensor allow them be integrated in to a visual programming interface. As a result logic can
be built around the different values the sensors return.
Figure 3. DFM Algorithm Flowchart
The logic that the DFM system will use has been illustrated in Figure 3. The sections that
have dotted lines around them have been elaborated on in separate flowcharts. The DFM system
will always run, but will not be active while the car is turned on. The decision to make the DFM
work only while the car is off is for safety. If the alarm system were to come on while someone
12
Lab 2 – Don’t Forget Me
if driving for any reason the system could in fact endanger one’s life. Once each hour the DFM
system will undergo the activation process as depicted in Figure 4. The system will then check
to see if the car is off before going any further.
When the car is turned off the first thing the system does is check for the reset preempt.
The alarm will go off if an occupant is present and the key fob is not detected, but the
temperature is still safe. It will also go off if an occupant is detected and the temperature is
unsafe regardless of the preempt status. Therefore, if someone wants to leave a person in the
vehicle who is capable of leaving, and the temperature is not dangerous they may do so without
the alarm system activating if they press the reset switch before the alarm goes off. When the
reset switch is used to prevent the alarm when the temperature is safe it is referred to as a
“preempt.”
After the preempt status is check the system checks the temperature in the vehicle. If the
temperature is greater than 90 degrees Fahrenheit, or less than 30 degrees Fahrenheit, then
temperature status will be indicated as dangerous. Next the Life Detection Algorithm depicted in
Figure 5 runs to determine if there is an occupant in the vehicle. In the event that the
temperature is dangerous and someone is in the vehicle the alarm system will immediately be
activated.
In the event that the temperature is not dangerous but life is detected the DFM
system will check if the key fob is in range. The range of the key fob is 20ft and should be
attached to the driver’s keys. If the key fob is not detected and an occupant is present the DFM
system will check the preempt set value. If the preempt is not set then the alarm system will be
activated and will not stop until someone presses the reset switch. The reset switch will then
restart the system and deactivate the alarm.
13
Lab 2 – Don’t Forget Me
Figure 4. DFM Activation Flowchart
Figure 4 elaborates on the activation process. The activation process is necessary to
continually test each of the sensors in the DFM system so the driver will be aware that the
system is not fully active and requires maintenance. The activation process starts with each of
the sensor sending a small amount of data to be tested. If the data is within a reasonable range
for that particular sensor and the data packet arrived in less than 1 second than that sensor is
validated. If any of the sensors fail validation the error value is returned and an error light will
be lit for the driver to see. The DFM will still try to run if the error is isolated to one of the
sensors, but will not run if the error is more severe.
14
Lab 2 – Don’t Forget Me
Figure 5. DFM Life Detection Algorithm
Figure 5. elaborates on the process the DFM system uses to determine if life is present in
the vehicle. Each sensor has a range of values that when returned indicate that life has been
detected by that particular sensor. After the sensor returns a value the value is checked to
determine if that sensor detected life. If the sensor indicates that if detected life a value based on
the priority of the sensor is added to a detection variable. If the variable’s value is greater than 5
then the algorithm has determined that life is present.
15
Lab 2 – Don’t Forget Me
2.3 External Interfaces
External interfaces section describes the different ways one may interact with the DFM
system.
2.3.1 Hardware Interfaces
The development team will use each of the sensors to supply data to the LabVIEW
software, the switch to disable or preempt the alarm, and the key fob to indicate the driver’s
location. There will be minimal interaction with the sensors since the fully implemented version
is not meant to interface with vehicle occupants. The temperature sensor will be manipulated so
that the system detects extreme hot and cold readings. The motion sensor, pressure sensor, CO2
sensor, and microphone will all gather data without human interaction. Therefore, the only
hardware that should ever directly be interacted with is the key fob, and reset switch.
2.3.2 Software Interfaces
The development team interfaces with the DFM system’s software through LabVIEW.
In LabVIEW a VI (virtual instrument) is created to represent each piece of hardware in the
system. The virtual instrument allows the development team to define the inputs, outputs, and
underlying logic behind each sensor. The virtual instruments are then integrated into the DFM
system in the same manner the hardware will be installed in the final product. The “Front Panel”
is the visual interface with the virtual instrument.
16
Lab 2 – Don’t Forget Me
Figure 6. Alarm VI Front Panel display
For example, in Figure 6 the Alarm VI is shown. The alarm takes the sound file, and the
two switches states (“Activate Alarm”, and “Stop Loop”) as input values, and outputs sound to
the computer speakers. The underlying logic for the alarm is displayed in Figure 7, which is
referred to as a “Block Diagram.” The block diagram is also composed of VIs; this makes it
simple program since all one needs to know is the type of input values the VI expects, the
operation the VI performs, and the type of outputs the VI will return. The entire DFM system
will be programmed with this method with each of the sensor’s values streaming in as VI inputs.
17
Lab 2 – Don’t Forget Me
Figure 7. Alarm VI Block Diagram
2.3.3 User Interfaces
The DFM interfaces with the user exclusively through LabVIEW or the reset switch.
Through LabVIEW one will be able to activate and deactivate the DFM system. At the point of
activation the DFM system will conduct a sequence of tests to ensure that all sensors are giving
valid data. Following the activation, the life detection sequence will run until the system is
deactivated through LabVIEW or until the alarm goes off. A user may preempt the alarm or
deactivate the alarm by pressing the reset switch. In the event of an error a message will be
displayed to the user.
18
Lab 2 – Don’t Forget Me
2.3.4 Communication Protocols and Interfaces
No specific protocol will be used in the DFM system. The driver will have access to key
fob that will transmit a radio frequency to the DFM system remotely. When the signal no longer
reaches the vehicle then the DFM system will know that the driver is out of range.
3 Specific Requirements
The following section describes the specific functional, performance, and non-functional
requirements of the DFM system prototype.
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.
3.1.1 DFM System Activation Process
This 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 described in section 2.2. The following
procedures must occur for the DFM system to be activated:
1.
Send a request for data from each of the sensor.
2.
Validate data from each sensor.
3.
Test circuit connected to the alarm system.
4.
Returns a signal to indicate that the system is working.
19
Lab 2 – Don’t Forget Me
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.
1.
Check each sensor for values that indicate life.
2.
If the sensor has a value or change in data that indicates life the detection value associated
with that sensor should be added to accumulation variable.
3.
If the variable has a value greater than five the life detection process indicates a positive
result.
4.
If the result of the life detection process is negative the process will run again with
entirely new data.
3.1.3 Alarm System
The following requirements detail the process in which the DFM determines that the
sensors are working and life is detected. Under the follow conditions the alarm system will be
activated.
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 temperature value is determined and set to dangerous is the value is less than 30º F or
greater than 90ºF.
5.
The life detection procedure runs, if the value is greater than 5 then an occupant is
detected.
6.
If the temperature is extreme and an occupant is detected the alarm system will activate.
20
Lab 2 – Don’t Forget Me
7.
If the alarm system was not activated the key fob is checked to determine if the driver
left.
8.
If the driver left and an occupant is detected the alarm system will activate.
9.
The alarm system is deactivated and the system is reset if the reset switch is pressed.
10. The system continues to check for extreme temperatures and occupants until the alarm
system is activated or the car is turned on.
3.2 Performance Requirements
The following performance requirements describe how well the aforementioned
procedures work in quantifiable terms. The following performance requirements directly relate
the procedures explained in the previous section.
3.2.1 System Activation Tests
In order to validate the sensors and the alarm system the hardware components will pass
the following requirements.
1.
Each sensors value will be greater than its minimum value.
2.
Each sensors value will be less than its maximum value.
3.
Each sensor will return a value in less than one second.
4.
The entire activation will take no more than ten seconds.
21
Lab 2 – Don’t Forget Me
3.2.2 Life Detection Tests
The life detection procedures shall meet the following performance requirements:
1.
Each sensors value will be greater than its minimum value.
2.
Each sensors value will be less than its maximum value.
3.
Each sensor will return a value in less than one second.
4.
The entire procedure will take no more than nine seconds.
3.2.3 Alarm System Tests
The alarm system procedures shall meet the following performance requirements:
1.
The system will iterate in less than 15 seconds.
2.
The activation procedure will be conducted once every hour.
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 2 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
30° F is the “cool” temperature
at which point alarm goes off.
90° F is the “hot” temperature at
which point alarm goes off.
Detection of pressure indicates
detection of occupant.
Occupant has no remarkable
medical conditions.
Occupant is appropriately
dressed for the weather.
Reset switch is not used
accidentally or maliciously.
Type
Assumption
Assumption
Assumption
Assumption
Assumption
Assumption
Effect on Requirements
Cooling device must be present at demonstration to
lower temperature.
Heating device must be present at demonstration to
raise temperature.
Prototype distinguishes between pressure and no
pressure; not between different pressures.
Medical conditions may affect input from pulse
oximeter.
Varied clothing affects effectiveness of the system.
Accidental or malicious use of the reset switch defeats
the purpose of the system.
22
Lab 2 – Don’t Forget Me
Condition
Type
Effect on Requirements
CO2 sensor is not incorporated
Constraint Input from CO2 sensor is simulated by the software.
into prototype.
Heartbeat is detected by pulse
Constraint Pulse oximeter must be attached to occupant’s finger.
oximeter.
Prediction of extreme
Constraint Alarm is only activated if an extreme temperature is
temperatures is not supported.
detected.
All sensors function properly at Dependency Prototype cannot be demonstrated without input from
time of demonstration.
the sensors.
PC or laptop with LabVIEW
Dependency Prototype cannot be demonstrated without the
installed is available at time of
LabVIEW software.
demonstration.
Table 3. Effects of Assumptions, Dependencies, and Constraints on Requirements
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
23
Lab 2 – Don’t Forget Me
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
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.
24
Lab 2 – Don’t Forget Me
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.
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
25
Lab 2 – Don’t Forget Me
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
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.
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.
26
Lab 2 – Don’t Forget Me
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
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.
4 Appendix
The appendix contains additional documentation for the DFM system prototype.
27
Lab 2 – Don’t Forget Me
4.1 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 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
Price
Company Qty 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
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:
5
6
Laptop/ Second computer
5.1 It will be used to display the interaction of hardware element and the
algorithm processes during the live prototype demonstration.
5.2 Windows XP with connection to the internet
5.3 Quantity: 1
5.4 Date required: March 1, 2008
5.5 Deliver to: Don’t Forget Me Inc.
LabVIEW installed on the Laptop
6.1 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.
6.2 LabVIEW must have the drivers installed for the DAQ used in the
prototype, a USB-6008.
28
$37.00
Lab 2 – Don’t Forget Me
6.3 Quantity 1
6.4 Date required: March 1, 2008
6.5 Deliver to: Don’t Forget Me Inc.
29