1
INTRODUCTION
stuff
1.1 Purpose
stuff
1.2 Scope
stuff
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.
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
(inter-operate).
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
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.
1.4 References
stuff
1.5 Overview
stuff
2
GENERAL DESCRIPTION
stuff
2.1 Prototype Architecture Description
stuff
2.2 Prototype Functional Description
stuff
2.3 External Interfaces
stuff
2.3.1 Hardware Interfaces
stuff
2.3.2 Software Interfaces
stuff
2.3.3 User Interface
Stuff
2.3.4 Communication Protocols and Interfaces
Stuff
3
SPECIFIC REQUIREMENTS
The following information provides specific information about the prototype.
Functional requirements, performance requirements, assumptions and constraints, and
non functional requirements will all be covered in this section. It is broke 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 #] 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.
3.1.1.2 Life Detection Sensors
The Life Detection Sensors [figure #] 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 #]. The sensors will meet the following functional
requirements.
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.
3.1.1.3 Environmental Sensor
The Environmental Sensors [figure #] 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.
1.) The temperature detector must detect the surrounding temperature within the
accuracy of .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 #]. The life detection procedures will meet the following functional
requirements.
1.) The DFM system will check each of the sensors for the values that indicate life
[figure #].
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.
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 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.
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.
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 t its rated maximum value.
4.) Each sensor will return a value within 10 seconds.
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.
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.
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.
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 #. 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 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.
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 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. 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 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
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
$37.00
The following University resources are required to support the prototype development
and demonstration:
1
2
Laptop/ Second computer
1.1 It will be used to display the interaction of hardware element and
the algorithm processes during the live prototype demonstration.
1.2 Windows XP with connection to the internet
1.3 Quantity: 1
1.4 Date required: March 1, 2008
1.5 Deliver to: Don’t Forget Me Inc.
LabVIEW installed on the Laptop
2.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.
2.2 LabVIEW must have the drivers installed for the DAQ used in the
prototype, a USB-6008.
2.3 Quantity 1
2.4 Date required: March 1, 2008
2.5 Deliver to: Don’t Forget Me Inc.