Don’t Forget Me CS 411W Lab II Prototype Product Specification

advertisement
CS 411W Lab II
Prototype Product Specification
For
Don’t Forget Me
Prepared by: Patrick Markham, Blue Team
Date: 03/04/2008
Markham, Patrick
2
Table of Contents
1
Introduction ................................................................................................................. 3
1.1
Purpose................................................................................................................ 4
1.2
Scope ................................................................................................................. 10
1.3
Definitions, Acronyms, and Abbreviations ...................................................... 11
1.4
References ......................................................................................................... 12
1.5
Overview ........................................................................................................... 12
2 General Description .................................................................................................. 13
2.1
Prototype Architecture Description .................................................................. 14
2.2
Prototype Functional Description ..................................................................... 17
2.3
External Interfaces ............................................................................................ 21
3 Specific Requirements .............................................................................................. 23
3.1
Functional Requirements .................................................................................. 23
3.2
Performance Requirements ............................................................................... 24
3.3
Assumptions and Constraints ............................................................................ 26
3.4
Non-Functional Requirements .......................................................................... 29
4 Appendix ................................................................................................................... 30
4.1
Formal Resource Request Document................................................................ 30
List of Figures
Figure 1.
Figure 2.
Figure 3.
Figure 4.
Figure 5.
Figure 6.
Figure 7.
Nontraffic fatalities involving children and automobiles, 2000-2004 ............. 4
Major Functional Component Diagram ........................................................... 7
Prototype Major Functional Component Diagram......................................... 13
Don’t Forget Me main algorithm ................................................................... 18
Don’t Forget Me life detection algorithm ...................................................... 20
Don’t Forget Me activation algorithm ........................................................... 21
Site map for the partner websites ................................................................... 18
List of Tables
Table 1. Feature comparison between full product and prototype.................................... 15
Table 2. Effects of Assumptions, Dependencies, and Constraints on Requirements ....... 26
Markham, Patrick
1
3
Introduction
More than 9,000 children received emergency room treatment for nonfatal
injuries related to nontraffic automobile incidents from July 2000 to June 2001 (Centers
for Disease Control and Prevention, n.d.). The same period saw more than 450 children
involved in over 350 nontraffic, noncrash incidents, resulting in at least 92 deaths.
figure has risen steadily each year.
This
Last year (2007), 942 children were involved in 725
such incidents, resulting in 231 deaths (kidsandcars.org, n.d.). The causes of death
include, primarily, hyperthermia and hypothermia, strangulation (e.g., in a vehicle
window or seatbelt), inhalation of vehicle-generated carbon monoxide and collision (i.e.,
backovers and frontovers).
Twenty-four percent of all nontraffic, noncrash fatalities involving
children in the years 2000 through 2004 were a direct result of neglect during excessively
hot temperatures (kidsandcars.org, n.d.). While 50% of such fatalities in the same years
resulted from backovers and frontovers, numerous commercially viable systems which
address collisions of this nature have since been introduced into the general market.
As
a result, data is expected--in several years' time--to reflect the introduction of these
solutions, in the form of a drastic decline in the percentage of fatalities resulting from the
collisions these solutions attempt to address.
At the same time, the data will show a
dramatic increase in the percentage of deaths resulting from other causes.
After
backovers, hyperthermia is the leading cause of nontraffic, noncrash fatalities involving
children by far. This is clearly shown in the diagram below:
Markham, Patrick
4
Figure 1. Nontraffic fatalities involving children and automobiles, 2000-2004.
1.1
Purpose
Conceived by the Old Dominion University (ODU) CS410/411 Blue Team, Don't
Forget Me (DFM) is a sensor-based occupant protection system that can be installed, at
the manufacturing level, in any vehicle.
It is a combination of sensors and software
which, in cooperation with a standard vehicle alarm, attempts to prevent the driver from
leaving a child unattended in a vehicle for any length of time. The system is designed
not only to inhibit intentional neglect, but also to act as an aid to the memory of the driver,
who is often hindered by stress or a busy schedule, among other factors.
By sounding
the vehicle alarm, the DFM system attempts to prevent the driver from stepping too far
away from the vehicle while an occupant remains inside.
If, in spite of the system's
efforts to prevent neglect in the first place, the occupant is left unattended in the vehicle
anyway, DFM notifies the driver again in the event that the occupant is exposed to
extremely hot or cool temperatures, or shows signs of a possible respiratory or circulatory
Markham, Patrick
5
problem.
There are five sensors altogether: one for detecting the presence of a heartbeat and
heartrate, one for seat pressure, one for CO2 level, one for motion and one for audio.
Each sensor is assigned a unique weight.
If the combined weight of the sensors is
greater than five, the system concludes that an occupant is present.
The weight system
is designed as a failsafe against faulty input to the sensors or one of the sensors
malfunctioning.
In other words, it is not necessary for all five sensors to detect an
occupant in order for the DFM system itself to determine that one is present.
If no audio
is detected, for example, the system is still capable of determining the occupant's
presence based on heartbeat and seat pressure.
If a sensor fails entirely, the system can
detect an occupant based on input from other sensors.
If no occupant is present, the DFM system does not set off the keyfob or the car
alarm under any circumstance. However, if one is present, the system attempts to
prevent the driver from leaving the occupant unattended by setting off the alarm if the
driver steps further than 20 feet away from the vehicle in any direction.
If the alarm
goes off, the only way to reset the alarm is to return to the vehicle and manually press a
reset switch. Returning to a distance of less than 20 feet from the vehicle will not turn
off the alarm.
The only way for the driver to leave an occupant unattended and step further than
20 feet away from the vehicle is to press the reset switch prior to leaving the vehicle.
However, in order to minimize the risk that the driver might press the reset switch out of
habit and then leave the occupant unattended unintentionally, the switch is located in the
backseat of the vehicle.
Therefore, to do this, the driver must step out of the vehicle and
Markham, Patrick
6
open a door to the backseat (i.e., where the driver will be forced to see the occupant and
make a conscious decision whether or not to leave them unattended).
Nevertheless, even if the driver presses the reset switch prior to leaving
the vehicle with the unattended occupant inside, the system is still active.
If the interior
of the vehicle approaches extremely hot or cool temperatures, or if an extremely fast or
weak heartrate is detected, both the keyfob and the car alarm will be set off.
In this case,
it is not enough to return to the vehicle and press the reset switch; if the interior of the
vehicle does not return to an acceptable temperature, the occupant must be removed from
the vehicle entirely.
The following is an illustration of the major functional components of the Don't
Forget Me system:
[This section of page intentionally left blank.]
Markham, Patrick
Figure 2.
Major functional component diagram
The first component is the heartbeat sensor.
indicates the presence of an occupant.
The presence of a heartbeat
Additionally, this sensor can determine if an
occupant is experiencing any sort of heart condition, trouble breathing or other problem
7
Markham, Patrick
8
which would result in a particularly high or low heartrate.
The second component is the pressure sensor. The presence of sufficient
pressure on a seat indicates the presence of an occupant.
The third component is the CO2 sensor. Since humans exhale CO2, the
presence of a sufficient level of CO2 indicates the presence of an occupant.
The fourth component is the motion sensor. The presence of motion indicates
the presence of an occupant.
The fifth component is the microphone. The presence of audio, such as a baby
crying, indicates the presence of an occupant.
The sixth component is the car alarm.
with the vehicle's existing car alarm.
The DFM system works in conjunction
The alarm serves primarily to prevent the
occupant from being left unattended in the first place. However, the alarm is also set off
in the event that the interior of the vehicle approaches extremely hot or cool
temperatures.
The seventh component is the temperature detector. This sensor determines the
temperature of the interior of the vehicle only.
The eighth component is the keyfob. This device is actually a combination of a
keychain beeper and a wireless receiver, as it must be able to communicate with the CPU.
If the driver steps further than 20 feet away from the vehicle in any direction, or if the
interior of the vehicle approaches extremely hot or cool temperatures, both the car alarm
and the keyfob are set off.
The ninth component is the remote detector. This device determines if the
keyfob is in proximity for communication.
Markham, Patrick
The tenth component is the transmitter device.
9
This is the wireless technology
necessary for such communication.
The eleventh major functional component is the reset switch. The reset switch
turns off the alarm.
It also allows the driver to step further than 20 feet away from the
vehicle; however, it is located in the backseat to mitigate the risk of leaving an occupant
unattended unintentionally.
The final major functional component is the Central Processing Unit
(CPU). The CPU includes a central processor (i.e., the computer hardware component),
an embedded operating system and the DFM software, outlined in section 2.1 of this
document.
DFM Inc. will target one market in particular: vehicle manufacturers. Vehicle
manufacturers produce over five million passenger cars and more than seven million
commercial vehicles annually.
From 1997 through 2005, the total number of vehicles
manufactured, both passenger cars and commercial vehicles, averaged 12,181,000
annually.
The goal is to capture 1-2% of this market in the first two years.
In other
words, the goal is to have the Don't Forget Me system installed on 1-2% of all vehicles
manufactured in the second year.
Further expansion, although difficult to project, is
expected to result from natural growth.
Alternatively, if federal legislation is introduced
that requires manufacturers to install safety measures meeting the general description of
the DFM system in their vehicles, DFM Inc. has the opportunity to dominate the market
decisively for years to come. Revenue will be derived from the sale of licenses to install
the system in the vehicles a manufacturer produces. The anticipated cost of a single
license to the manufacturer is fifty U.S. dollars.
The figure below details the number of
Markham, Patrick 10
vehicles manufactured annually for the 1997-2005 period.
1.2
Scope
The prototype of the Don't Forget Me system is designed to demonstrate the
feasibility of (1) using a combination of sensors and software to detect the presence of an
unattended occupant, (2) alarming the driver if he steps too far away from an unattended
occupant, and (3) alarming the driver if the occupant is left unattended anyway, in the
event that the occupant is exposed to dangerous conditions inside the vehicle (primarily,
if the interior of the vehicle becomes too hot or too cool). The first functional objective
is to successfully demonstrate the system's ability to detect an occupant.
There are
multiple sensors involved in the detection of an occupant, and it must be demonstrated
that each sensor can detect what it is designed to detect (if pressure, pressure; if a
heartbeat, heartbeat; etc.), and that the sensors can communicate with the software.
Additionally, it must be demonstrated that the DFM system does not conclude that an
occupant is present unless and until the combined "weight" of the sensors involved is
greater than five. Each sensor is given a weight, and the detection of life by any one
sensor is not sufficient to conclude that an occupant is present.
On the other hand, the
failure of any one sensor to detect life is not sufficient to conclude that an occupant is not
present.
The algorithm which defines this weight system (discussed later), must
therefore also be demonstrated.
The second objective is to demonstrate the key fob and the initial alarm.
It must
be shown that the driver can step away from the vehicle (in this case, the laptop and the
sensors) if no occupant is present in the vehicle; it must also be shown that, if an
occupant is present, the driver can only step so far away from the vehicle without setting
Markham, Patrick 11
off the alarm, and that he must return to the vehicle and manually reset the alarm in order
for it to stop.
Third, it must be shown that if conditions subsequently endanger the
occupant (i.e., if the temperature becomes too hot or too cool), the driver is notified via
both the alarm and the key fob, in spite of his having walked away from the vehicle.
This will involve separate demonstrations for when the temperature becomes too hot as
opposed to when the temperature becomes too cool.
Once again, the alarm must not
shut off until the driver has returned to the vehicle and physically pressed the reset switch.
Finally, it must also be shown that the temperature inside the vehicle will not set off the
alarm if no occupant is inside.
The final objective is to show the flexibility of the algorithm by allowing a
member of the review board to dictate the conditions, and compare the actual reaction of
the DFM system to the expected reaction.
1.3
Definitions, Acronyms, and Abbreviations
Accelerometer: A heartbeat sensor.
BluTooth:
A wireless communication technology.
DAQ: National Instruments' USB-6008 or -6009 Data Acqusition device.
DFM:
Don't Forget Me. Usually the Don't Forget Me system or the Don't Forget Me
software.
DFM Inc.:
The Don't Forget Me company.
Key fob: A decorative or functional item attached to a key ring or key chain, able to
communicate with a vehicle device such as the vehicle alarm, the door locking
mechanism, etc.
Markham, Patrick 12
LabVIEW:
Software included in National Instruments' Data Acquisition Kit for use
with the DAC.
Microcontroller:
In computers, the hardware responsible for all calculations, along with
some amount of software.
MFCD: Major Functional Component Diagram.
ODU: Old Dominion University.
Pulse Oximeter:
A device that detects a heartbeat and heartrate based on the amount of
light that can pass through the bloodstream.
Unlike the accelerometer, the pulse
oximeter must be attached to a finger.
1.4
References
Centers for Disease Control and Prevention. (n.d.).
Retrieved January 21, 2008,
from Centers for Disease Control and Prevention Website:
Kids and Cars. (n.d.).
Website:
http://www.cdc.org/
Statistics. Retrieved January 21, 2008, from Kids and Cars
http://www.kidsandcars.org/
National Instruments. (n.d.).
NI USB-600x Student Kits. Retrieved January 21, 2008,
from National Instruments Website:
http://sine.ni.com/nips/cds/view/p/lang/en/nid/14681
1.5
Overview
This product specification provides the hardware and software configuration,
external interfaces, capabilities and features of the Don't Forget Me prototype. The
information provided in the remaining sections of this document includes a detailed
description of the hardware, software, and external interface architecture of the Don't
Forget Me prototype; the key features of the prototype; the parameters that will be used
Markham, Patrick 13
to control, manage, or establish these features; and the performance characteristics of
these features in terms of inputs, outputs, and user interaction.
2
General Description
The prototype of the Don't Forget Me system will focus on the innovative design
of a combination of sensors and software, in cooperation with a standard vehicle alarm.
Some aspects of the full system, such as alarming the driver when the heartrate is
extraordinarily fast or weak, will not be simulated due to time and budget constraints.
[This section of page intentionally left blank.]
Markham, Patrick 14
2.1
Prototype Architecture Description
Figure 2. Phase 1 prototype major functional component diagram.
Markham, Patrick 15
Figure 2 illustrates the major functional components of the Don't Forget Me prototype
and the relationships between them.
It simplifies the components shown in Figure 1 but
retains the basic innovative functionality.
In the prototype, the microcontroller is
simulated by a laptop running LabVIEW software, the vehicle alarm is simulated by an
audio file and input from the CO2 sensor is simulated by the software.
Table 1 provides a summary of the differences between the full Don’t Forget Me
system and the prototype discussed above.
Features
Heartbeat Sensor
CO2 Sensor
Temperature Sensor
Motion Sensor
Actual Product
An accelerometer will be
installed that is capable of
sensing a heartbeat through
the vehicle’s 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 heartrate.
The sensor will measure the
level of CO2 in the vehicle.
A steady increase will
indicate there is no
ventilation and there is an
occupant in the vehicle.
The temperature sensor will
read in very precise values
to determine the rate of
temperature change, in
order for the software to
determine when a threat is
imminent.
The software will analyze
the values read from the
motion sensor over time to
determine if the readings
are influenced by an
occupant.
Prototype
A pulse oximeter is attached
to a volunteer’s finger.
This device gives the same
input values as the
accelerometer, but requires
the volunteer to attach the
device. Additionally, the
software will only monitor
the presence of a pulse, not
the heartrate.
No CO2 sensor is used for
the prototype. Rather, the
sensor is simulated in
LabVIEW.
A temperature sensor reads
the current temperature of
the room, and the software
decides not if a dangerous
temperature is imminent,
but if the temperature is
already dangerous.
The motion sensor reads in
several values over a short
time period. If motion is
detected over that time
period, then the software
assumes that an occupant is
present, at least as far as the
motion sensor is concerned.
Markham, Patrick 16
Pressure Sensor
As with the motion sensor,
the values given to the
software will be used to
determine if there is a
pattern that indicates the
presence of an occupant.
Microcontroller/CPU
A microcontroller will be
used to run 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
any/all occupants.
Reset Switch
A switch will be placed in
the rear of the vehicle so
that the driver can manually
shut off the alarm in case of
a false alarm. However, the
system will still set off the
alarm if it detects an
occupant is in danger.
A receiver will be placed in
the car with the generator as
a keyfob. When the
generator goes out of range
(20 ft.), the car’s alarm will
sound.
The alarm will be
implemented according to
the preference of the
manufacturer. It is strongly
recommended that the
vehicle’s built-in horn or
alarm system be used given
the public’s familiarity with
car alarms.
A simple microphone will
be integrated into the DFM
system in the middle rear
section of the vehicle,
behind the seat. The
Infrared
Receiver/Transmitter
Alarm
Microphone
The sensor is placed under a
cushion for the volunteer to
activate. By sitting, he or
she activates the pressure
sensor. This simulates a
child sitting in a rear or
safety seat.
LabVIEW simulation
software is run in order to
implement all the logic
necessary to run the DFM
system. Rather than having
the sensors wired into a
microcontroller, they
simply interface with the
underlying software using
an input/output device
known as a DAQ.
A switch is added to the set
of hardware, but the logical
implementation is not as
elaborate.
The same implementation
takes place, but the
generator is not in the form
of a keyfob.
A small speaker is used to
generate noise and simulate
a car alarm.
The computer’s microphone
will be used in conjunction
with LabVIEW to
determine if the decibel
level has reached a
Markham, Patrick 17
microphone will merely
predefined level.
check the intensity of noise
in the vehicle. In the event
that the noise is above a
predefined decibel level, the
software will determine an
occupant is present, at least
as far as the microphone is
concerned.
Table 1. Feature comparison between full product and prototype.
2.2
Prototype Functional Description
The major functional components are shown in Figure 2 above. The appropriate
response of the system given a set of inputs is determined by the software (simulated by a
set of LabVIEW constraints in the prototype), which follows the main DFM algorithm.
As per this algorithm, the system is only activated if the vehicle is unattended and life is
detected, indicating an unattended occupant.
If an occupant is not present, the system is
not activated, and the alarm does not sound under any circumstances.
If an occupant is present, however, the system is activated, and the alarm sounds
when certain conditions are met. Once activated, the system can be reset, but it can not
be shut off completely.
As long as the key fob is in range (i.e., the driver remains close
to the vehicle), and as long as the temperature on the interior of the vehicle remains at an
acceptable level, the alarm does not sound.
If, however, the key fob is in range, but the
temperature becomes too hot, the alarm sounds, and the it does not shut off until it is
determined that the occupant has been removed from the vehicle.
the key fob is in range, but the temperature becomes too cool.
The same is true if
If the key fob goes out of
range (i.e., if the driver strays from the vehicle), the alarm sounds, and it does not shut off
until the reset switch (located on the interior of the vehicle) is triggered, ensuring that the
driver has physically returned to the vehicle.
Markham, Patrick 18
If the reset switch is triggered, the key fob may go out of range without the alarm
sounding. If the key fob goes out of range, and if conditions inside the vehicle remain
acceptable, the alarm does not sound. However, if the key fob goes out of range, and if
the temperature inside the vehicle becomes too hot, the alarm sounds, and it does not shut
off until the occupant is removed from the vehicle.
The same is true if the key fob goes
out of range, and if the temperature becomes too cool.
Figure 4. Don’t Forget Me main algorithm.
The diagram above outlines the main DFM algorithm.
It shows the effect that the
presence of an occupant has on the response of the system, but it does not show how the
system determines if an occupant is present or not.
Determining whether occupant is
present or not is more involved than simply detecting a heartbeat.
If the heartbeat
sensor fails, or if the sensor detects the heartbeat of a passerby (i.e., not an occupant),
then the DFM system fails to respond appropriately.
For this reason, multiple sensors
Markham, Patrick 19
help to determine if an occupant is present, and each sensor is given a unique "weight."
For example, a heartbeat has a weight of four, and seat pressure has a weight of two. As
a result, a second algorithm was developed to determine the presence of an occupant.
There are a total of five sensors involved:
one for the detection of a heartbeat, one for
seat pressure, one for CO2, one for motion and one for audio.
First, each sensor checks
for an occupant individually. The pulse oximeter checks for a pulse; the motion
detector checks for motion; and so on. Second, a total weight is calculated by summing
the appropriate weight for each sensor that detects life. Finally, the system calculates
whether or not the total weight is greater than five.
If the total is greater than five, the
system concludes that an occupant is, in fact, present.
If the total is less than or equal to
five, then the system concludes that an occupant is not present.
[This section of page intentionally left blank.]
Markham, Patrick 20
Figure 5.
Don’t Forget Me life detection algorithm.
The main algorithm (Figure X) also fails to illustrate how the system determines
if it is functioning properly or not.
If the system is not functioning properly, it will
notify the driver via a light on the dashboard, in the same way that vehicles currently
notify the driver in the event that there is a problem with the battery, or if oil is low.
The DFM system performs a self-test each time it is activated. Figure 4 shows how it
determines whether or not to notify the driver of a problem with one or more of its
components. Essentially, it checks each sensor individually, and if even one sensor is
not responding, the driver is notified.
Markham, Patrick 21
Figure 6.
2.3
Don’t Forget Me activation algorithm.
External Interfaces
External interfaces are limited to pre-installed hardware and a key fob.
2.3.1 Hardware Interfaces
An ODU student laptop, combined with a Data Acquisition (DAQ) unit, a
breadboard and a few resistors, is used to read input from a series of sensors.
2.3.2 Software Interfaces
Markham, Patrick 22
The laptop is unable to read the input from the sensors without the LabVIEW
software and the pre-programmed algorithms.
2.3.3 User Interfaces
There are three main interfaces for the user.
First is the alarm.
If there is driver
steps too far away from the vehicle, or an occupant is in danger, the alarm sounds.
Second is the key fob, which communicates the driver's distance from the vehicle
to the DFM system automatically, and also sounds if there is a danger to the occupant.
The third interface is the reset switch.
If the alarm sounds, the only way to shut
the alarm off is to manually press the reset switch, located in the back seat of the vehicle.
Finally, the user is notified of a problem with one or more components of the
system via a light on the dashboard.
An additional hardware interface for connecting a laptop to the system also exists,
but is available only to vehicle service locations.
2.3.4 Communication Protocols and Interfaces
The BluTooth protocol is the only communication protocol employed, as it is
necessary for communication between the microcontroller and the key fob.
3
Specific Requirements
The following section describes the specific functional, performance, and non-functional
Markham, Patrick 23
requirements of the Don't Forget Me prototype.
3.1
Functional Requirements
The functional requirements describe the capabilities of the Don't Forget Me
prototype. They describe what the prduct must do in order to meet the previously
discussed goals and objectives of the project.
3.1.1 Alarm Interface
The alarm interface shall provide a mechanism for notifying the driver either that
he has stepped too far away from the vehicle, or that there is a danger to the occupant.
This interface involves one-way communication between the microcontroller and the
driver, using a standard vehicle alarm.
3.1.2 Key Fob Interface
This function shall provide a mechanism for determining the distance of the driver
to the vehicle, and for notifying the driver if there is a danger to the occupant.
The
following functional capabilities shall be provided as part of the key fob interface:
1.
Allow for two-way BluTooth communication between the key fob and a receiver
connected to the microcontroller, allowing the system to determine if the key fob
is in or out of range based on the reception or non-reception of a signal.
2.
Allow for two-way BluTooth communication between the key fob and a receiver
connected to the microcontroller, and for the activation of a vibe and/or light,
allowing the system to notify the driver if there is a danger to the occupant.
Markham, Patrick 24
3.1.3 Reset Switch
The reset switch must allow the driver to manually press a button to temporarily
deactivate the alarm.
3.1.4 Dashboard Interface
The dashboard light must display if the system determines that one or more
components is not responding.
3.1.5 Service Interface
Authorized persons (e.g., vehicle service locations) must be able to connect a
laptop to the microcontroller for diagnostics purposes.
3.2
Performance Requirements
The following performance requirements describe how well the functions of the
Don't Forget Me prototype shall be performed in quantifiable and measurable terms.
These requirements each correspond directly to one or more related functional
requirements, and they provide quantifiable and measurable goals for the service. The
test cases currently under development will be used to verify the attainment of these
goals.
3.2.1 Alarm Module
The alarm module shall meet the following performance requirements:
1.
Sound alarm if key fob goes out of range vehicle contains occupant(s); do not shut
off until reset switch is triggered.
Markham, Patrick 25
2.
Sound alarm if temperature inside vehicle reaches 90 degrees Fahrenheit and
vehicle contains occupant(s); do not shut off until occupant is removed from
vehicle.
3.
Sound alarm if temperature inside vehicle reaches 30 degrees Fahrenheit and
vehicle contains occupant(s); do not shut off until occupant is removed from
vehicle.
3.2.2 Reset Switch Module
The reset switch module shall meet the following performance requirements:
1.
Temporarily disable alarm for two minutes if reset switch is triggered.
3.2.3 Dashboard Module
The dashboard module shall meet the following performance requirements:
1.
Display light if system determines that one or more components is not responding.
3.2.4 Service Module
The dashboard module shall meet the following performance requirements:
1. Display input from sensors to authorized laptops connected to microcontroller.
3.3
Assumptions and Constraints
Table 2 contains the full list of assumptions, constraints, and dependencies for the
prototype.
Condition
Type
Effect on Requirements
Markham, Patrick 26
30° F is the “cool” temperature
Assumption
Cooling device must be present at demonstration to
at which point alarm goes off.
lower temperature.
90° F is the “hot” temperature at Assumption
Heating device must be present at demonstration to
which point alarm goes off.
raise temperature.
Detection of pressure indicates
Assumption
detection of occupant, so far as
Prototype distinguishes between pressure and no
pressure; not between different pressures.
pressure sensor is concerned.
Occupant has no remarkable
Assumption
medical conditions.
Occupant is appropriately
oximeter.
Assumption
dressed for the weather.
Reset switch is not used
Assumption
Accidental or malicious use of the reset switch defeats
the purpose of the system.
Constraint
into prototype.
Heartbeat is detected by pulse
Varied clothing would affect pre-defined "extremely
hot" and "extremely cool" temperatures.
accidentally or maliciously.
CO2 sensor is not incorporated
Medical conditions may affect input from pulse
Input from CO2 sensor is simulated by the
software.
Constraint
Pulse oximeter must be attached to occupant’s finger.
Constraint
Alarm is only activated if an extreme temperature is
oximeter.
Prediction of extreme
temperatures is not supported.
detected.
Markham, Patrick 27
Climate inside demonstration
room is outside control of DFM
Constraint
Extremely hot and cool temperatures must be simulated
by use of electric heater and bucket of ice.
team.
All sensors function properly at
time of demonstration.
PC or laptop with LabVIEW
installed is available at time of
Dependency Prototype cannot be demonstrated without input from
the sensors.
Dependency Prototype cannot be demonstrated without the
LabVIEW software.
demonstration.
Table 2. Effects of Assumptions, Dependencies, and Constraints on Requirements.
Markham, Patrick 28
3.3.1 Assumptions
Quite a few assumptions are made for the prototype. As shown in the table
above, these include the pre-defined "extremely hot" and "extremely cool" temperatures,
that the occupant has no remarkable medical conditions and is appropriately dressed for
the weather, that the reset switch is not triggered accidentally or maliciously, and that
detection of any pressure--as opposed to detection of pressure that falls into a particular
range--indicates detection of an occupant, so far as the pressure sensor is concerned.
3.3.2 Constraints
Three constraints have been identified. Due to budget and time concerns, no
CO2 sensor was purchased. As a result, input from the CO2 sensor is simulated entirely
by software.
Second, heartbeat and heartrate is detected by a pulse oximeter, not an
accelerometer. As a result, the device which detects heartbeat and heartrate must be
attached to the finger of a volunteer.
Third, prediction of extreme temperatures is not supported; the system will only
alert the driver of a temperature-related danger if a pre-defined "extremely hot" or
"extremely cool" temperature is detected.
Finally, the climate inside the demonstration room is outside the control of the
team.
Therefore, an electric heater is used to force the temperature to increase, and a
bucket of ice is used to force the temperature to decrease.
Markham, Patrick 29
3.3.3 Dependencies
Only one dependency has been identified at this point: all sensors must function
properly at the time of demonstration.
3.4
Non-Functional Requirements
Non-functional requirements address features of the prototype that are outside of
the core innovative functionality.
3.4.1 Security
Only authorized persons (e.g., vehicle service locations) should be able to
interface with the microcontroller using a laptop.
How to prevent unauthorized persons
from interfacing with the microcontroller has yet to be determined.
3.4.2 Maintainability
Sensors are prone to breaking and malfunctioning.
For this reason, vehicle
service locations must be equipped with the software necessary to interface with the
DFM microcontroller, for diagnostics purposes.
Additionally, service locations must
have the ability to order hardware replacement parts, and be equipped with the
knowledge of how to replace each part.
[This section of page intentionally left blank.]
Markham, Patrick 30
3.4.3 Reliability
The Don't Forget Me prototype must self-test and determine whether or not to activate
each time it is turned on.
Once active, it may be reset, but it must not be deactivated
until both the driver and any/all occupants have left the vehicle entirely.
4
Appendix
The appendix contains additional documentation for the Don't Forget Me
prototype.
4.1
Formal Resource Request Document
Team: Blue Team
Project Manager: Brandon Fields
The following resources are required to be purchased for the prototype development
and demonstration of the Don’t Forget Me product:
Hardware Purchase (list all items required for purchase):
Part Description
Part #
Sensor, Ultrasonic, 40Khz, Tran
136654
Sensor, Pressure, 0-1.45 PSI
218827
Kit, Infrared Tran and Rec
Linerar Thermistor Air Temperature
Pulse Oximeter
177092
OL-706
http://www.fitness-equipment.com/acatalog/
Online_Catalog_Pulse_Monitor__Ear_Clip
_
for_Pulse_Monitor_1034.html
P-703A
USB-6009 Kit (LabVIEW and DAQ)
779320-22
Company
Jameco.co
m
Jameco.co
m
Jameco.co
m
Omega.com
Fitness-Equ
ipment
NI.com
Qty
Price Ea
Total
2
$7.95
$15.9
2
$8.99
$19.9
2
1
$24.95
$61.00
$49.9
$68.0
2
2
$19.99
$159.00
$39.9
$331.
Markham, Patrick 31
Software Purchase (list all items required for purchase):
Part Description
FRAPS - Real-time video render
software
Part #
Company
Qty
Price Ea
Total
N/A
Fraps.com
1
$37.00
$37.00
The following university resources are required to support the prototype development
and demonstration:
None.
Date required: October 12, 2007
Download