CS 411W Lab II Prototype Product Specification For

advertisement
CS 411W Lab II
Prototype Product Specification
For
Don’t Forget Me
Prepared by: Hernan Gonzales, Blue Group
UID: #6010
02/25/08
Gonzales 02/25/08
Table of Contents
1
Introduction ................................................................................................................. 1
1.1
Purpose................................................................................................................ 1
1.2
Scope ................................................................................................................... 4
1.3
Definitions, Acronyms, and Abbreviations ........................................................ 5
1.4
References ........................................................................................................... 6
1.5
Overview ............................................................................................................. 7
2
General Description .................................................................................................... 7
2.1
Prototype Architecture Description .................................................................... 7
2.2
Prototype Functional Description ..................................................................... 12
2.3
External Interfaces ............................................................................................ 14
3
Specific Requirements .............................................................................................. 19
3.1
Functional Requirements .................................................................................. 19
3.2
Performance Requirements ............................................................................... 20
3.3
Assumptions and Constraints ............................................................................ 22
3.4
Non-Functional Requirements .......................................................................... 24
4
Appendix ................................................................................................................... 25
4.1
Formal Resource Request Document................................................................ 25
List of Figures
Figure 1. The DFM system Major functional component diagram .....................................4
Figure 2. The DFM system Prototype Major functional component diagram ....................9
Figure 3. The DFM system activation algorithm ..............................................................12
Figure 4. The DFM system life detection algorithm .........................................................14
Figure 5. USB-6009 data acquisition device .....................................................................15
Figure 6. Pulse oximeter sensor.........................................................................................15
Figure 7. Ultrasonic motion sensor ...................................................................................16
Figure 8. Pressure sensor ...................................................................................................16
Figure 9. Linear thermistor air temperature ......................................................................16
Figure 10. Infrared transmitter ..........................................................................................17
Figure 11. Infrared receiver ...............................................................................................17
Figure 12. Laptop speaker .................................................................................................17
Figure 13. Laboratory virtual instrumentation engineering workbench software .............18
List of Tables
Table 1. The DFM system sensors priority table .................................................................8
Table 2. Feature comparison between full product and prototype.....................................11
Table 3. The DFM system assumptions, constraints, and dependencies ...........................23
2
Gonzales 02/25/08
1
1 Introduction
There were 846 fatalities between 2001 and 2005 that were reported due to non-traffic
incidents involving children less than 15 years old; 23% or 195 cases were children left inside
the car, dying due to heat (Kids and Cars, 2007). The incidents keep on increasing every year,
and the numbers of deaths are even more than airbag accidents. Some vehicle manufacturers try
to prevent death of children inside the car, but the problem still continues. Typically, most of the
vehicle manufacturers use only one kind of sensor, which gives them no option in case the sensor
fails. A lot of companies thrive to give their best solution to the most ignored serious problem,
which is death of children after the driver has left the vehicle; however, they still do not have the
correct solution.
The Old Dominion University CS410 Blue Team came up with the best idea to save the
children from getting left behind inside the vehicle. The product is called the Don’t Forget Me
system (the DFM system), and its primary task is to save lives. The DFM system is made up of
multiple sensors, algorithms, and alerts that interact with each other to prevent and detect an
occupant inside a vehicle. The DFM system also alerts the driver and the people around the
vehicle that someone is left behind inside the vehicle. The DFM system is more accurate than
what most vehicle manufacturers are currently using. DFM Inc will patent the idea and sell the
license to some large vehicle manufacturers. The vehicle consumers will surely benefit from the
cutting edge vehicle child safety system that is designed by DFM Inc.
1.1 Purpose (Gonzales, 2008)
Gonzales 02/25/08
2
DFM is a system that the ODU CS410 Blue Team believes is the best solution to the
most ignored serious problem nowadays, which is death of children after the driver has left the
vehicle. This type of system is more accurate than what most vehicle manufacturers are currently
using. The system combines all the security features to make it more accurate when it comes to
saving lives.
The DFM system has two basic approaches. First, it detects if there is life inside the
vehicle. Second, it informs the vehicle owner and the people within the vehicle’s perimeter that
someone is left inside the vehicle in a hostile condition. The DFM system is automatically
activated once the driver with the receiver (embedded inside a key fob) is within the transmitter’s
perimeter (located inside the vehicle) and the sensors detect the occupant anywhere inside the
vehicle. All data from the sensors are passed to the algorithm, which decides the result using a
set of conditions that analyze the inputs. The system will remain in the waiting stage until the
driver with the key fob walks away from the vehicle. Once the driver goes beyond the set limit
and sensors still detect an occupant in the vehicle, the alarm goes off. There are two ways to stop
or prevent the alarm from going off: to remove the occupant from the vehicle and to manually
switch off the system that is located near the passenger seat.
The Major Functional Component Diagram is mainly composed of sensors, a controller, a
transmitter, and a receiver. In addition to the temperature sensor, there are five sensors that
detect if there is an occupant inside the vehicle: heartbeat, pressure, motion, microphone, and c02
sensors. The temperature sensor is a digital device that determines the temperature inside the
vehicle. Temperature reading from the sensor can run from 0-130 °F. The heartbeat sensor is
located near the occupant’s usual location for a precise reading, and it basically measures the
vibrations over time and matches them to the known human heartbeat pattern. The pressure
Gonzales 02/25/08
3
sensor is placed underneath the seat’s upholstery where the occupant sits. It recognizes the
average weight of an occupant when the occupant is sitting in the car seat, and it filters out the
rest of the unknown weights. The motion sensor detects any movements inside the vehicle. It
ignores the vibrations outside the vehicle. A microphone detects the amount of sounds measured
in decibels inside the vehicle. The c02 sensor measures the amount of accumulated carbon
dioxide inside the vehicle.
All of the sensors are attached to the main controller. The main controller has software
that analyzes all the inputs from the sensors and determines the logical result. In short, the
controller is the brain of the entire system that distinctly decides what actions to consider. If all
the input data match the emergency signal, then the controller activates the vehicle horn and it
uses the transmitter to send a signal to the key fob to beep. The housing of the devices are
depending on the preferences of the vehicle manufacturers.
Gonzales 02/25/08
4
Figure 1. The DFM system Major functional component diagram
1.2 Scope
The purpose of the DFM system prototype is to show the feasibility of the product.
There are three objectives for the functional prototype: to successfully demonstrate the use of the
Gonzales 02/25/08
5
sensors by detecting life, to prove the accuracy of the algorithm with its decision, and to show
that the algorithm produces an output. The first objective is to show that the sensors are
detecting life. DFM Inc will demonstrate the detection of life using different kinds of sensors.
The sensors that DFM Inc will be using are the temperature, pulse, motion, pressure,
microphone, and c02 sensors. All of them will be demonstrated using real sensors except for the
c02 sensor. C02 will be simulated using the LabView program.
The second objective is to show the accuracy of the DFM system’s algorithm. All
sensors will be connected to the Data Acquisition (DAQ) device called USB-6009. The USB6009 with all the sensors attached to it will be connected to a laptop. The laptop has the
algorithm coded in the LabView program. The DFM system algorithm is coded in the LabView.
The DFM Inc will run the LabView application program to show that the algorithm processes all
the data received from the sensors accurately and shall produce an appropriate action.
The final objective is to show that the algorithm produces an output. The algorithm will
be receiving input data from the sensors and should produce an output. The output can have a
true or false value. True value means that life is detected and the temperature is too high or too
low; however, false values means no life is detected or temperature is in normal condition.
There will be a sound from the computer speaker if the result from the algorithm is true.
The prototype components are different from real world product; however, the prototype
devices have almost the same characteristics with the real product. All prototype components
will be tested in front of the review panel.
1.3 Definitions, Acronyms, and Abbreviations
DFM Inc – Don’t Forget Me Incorporated. Refer to the group.
Gonzales 02/25/08
6
The DFM system – Short for the Don’t Forget Me system. It is a vehicle security system created
by DFM Inc.
DAQ – Stands for Data Acquisition. DAQ device is used for data acquisition or sensors control.
USB – Stands for Universal Serial Bus. Usually used for connecting computers/devices
USB-6009 – A Data Acquisition device with USB ports.
GUI – Stands for Graphical User Interface.
LabView – Stands for Laboratory Virtual Instrumentation Engineering Workbench. It is a
graphical computer software that is used for data acquisition.
Occupant – The person inside the car.
KHz – Stands for Kilohertz
Decibels – Measurement of sounds
dB – Stands for Decibels
PSI – Pounds per Square Inch
Boolean – An argument that has only true or false values
1.4 References
Gonzales, Hernan. (2008 Spring). Lab I - Don’t Forget Me. Norfolk, VA: Author.
Jameco Electronics. (2008). Jameco Electronics. Retrieved February 19, 2008, from
Jameco Electronics Web site: http://www.jameco.com/ Jameco/catalogs/c281/P134.pdf.
National Instruments Corporation. (2008). National Instruments. Retrieved February 19,
2008, from National Instruments Corporation Web site: http://www.ni.com/pdf/
products/us/20043762301101dlr.pdf.
Markham, Patrick. (2008 Spring). The DFM system assumptions, constraints, and dependencies.
[Table 3] Table created during CS 411 at Old Dominion University.
Gonzales 02/25/08
7
Fields, Brandon. (2008 Spring). Feature comparison between full product and prototype. [Table
2] Table created during CS 411 at Old Dominion University.
DFM Inc. (2008 Spring). The DFM System. Retrieved March 02, 2008, from Puchicho Web
site: http://www.puchicho.com.
1.5 Overview
This product specification provides the software configuration and all the hardware
involved in the DFM prototype. In the remaining section of this document, the software,
hardware, and interface architectural design of DFM prototype are discussed in specific details.
2 General Description
The prototype of the DFM system will focus on its innovative aspect of integrating
different sensors. The unique part of the prototype is the logic behind the algorithm. The DFM
Inc will use the algorithm to analyze the data input from the sensors to generate an outcome.
2.1 Prototype Architecture Description
The DFM system prototype is primarily composed of an after market temperature sensor,
a pulse sensor, a motion sensor, a pressure sensor, a microphone, and a c02 sensor. C02 sensor
is simulated due to its complexity in nature, and the rest of the sensors are real. The tools that
DFM Inc uses for data analysis are: DAQ device, laptop computer, and LabView application
software. The result can only be positive or negative. Positive assumes there is an occupant left
inside the vehicle in an extremely hot or cold condition. Otherwise, the result is negative. An
Gonzales 02/25/08
8
alarm might also be used to stress the result. All the sensors are attached to the DAQ, and the
DAQ is connected to a laptop computer. The laptop computer has a LabView program that acts
as the GUI and the algorithm of the system. The algorithm will weigh all the data input from the
sensors depending on their priority values. Table 1 below shows the priority values of the five
sensors.
Sensor
Priority Value
Pulse Sensor
4
Motion Sensor
3
CO2 Sensor
3
Pressure Sensor
2
Microphone
1
Table 1. The DFM system sensors priority table
Each sensor has a predefined priority value. The pulse sensor has the highest priority
value of four. Next the motion and c02 sensors that have a priority value of three. Lastly are the
pressure sensor and the microphone that have priority values of two and one respectively. Every
sensor that detects life should hold their priority value; however, sensors that do not detect life
should hold a value of zero. The algorithm will sum up all the priority values obtained from the
sensors until the total value reaches greater than five. Once the sum of the priority values is
greater than five, the algorithm will send a signal to the laptop speaker to produce noise.
Gonzales 02/25/08
9
Figure 2. The DFM system Prototype Major functional component diagram
Capabilities of the prototype are less efficient than the real-world product. The DFM
system prototype only meets the minimum requirements of the real-world product. Table 2
below gives an overview of the differences between the real-world product and the prototype.
Features Comparison Table
Gonzales 02/25/08
10
Features
Real-World
Prototype
Heartbeat Sensing
An accelerometer will be installed
that is capable of sensing a
heartbeat through the vehicles back
seat. The accelerometer can detect
small fluctuations in movement,
thereby indicating a heart rhythm.
It will also be used to monitor
health based on rhythm.
A pulse oximeter will be attached
to a volunteer’s finger. This
device will give the same input
values of the accelerometer, but
will require the volunteer to attach
the device. Likewise, the presence
of a pulse will be the only criteria,
not rhythm.
CO2 Sensor
The sensor will measure the level
of CO2 in the vehicle. A steady
No CO2 sensor will be used for the
increase will indicate there is no
prototype, rather the sensor will be
ventilation and human or animal is simulated in LabVIEW.
present.
The temperature sensor will read in
very precise values to determine
Temperature Sensor the rate of temperature change to
determine when a threat may
become imminent.
A temperature sensor will read the
current temperature of the room
and indicate when the level
becomes too dangerous for a
human.
Motion Sensor
The software will analyze the
values read from the motion sensor
over time to determine if the
readings may be influenced by a
person. An instance of motion
without life would be the
movement of the vehicle’s air
conditioning vents.
The motion sensor will read in
several values over a short time
period. If motion is detected over
that time period, then the software
will assert that a person is present.
Pressure Sensor
Like the motion sensor, the values
given to the software will be used
to determine if there is not a pattern
that could indicate life. This would
mitigate false alarms due to devices
that could trigger the sensor, such
as a child’s mechanical toy.
The sensor will be placed under a
cushion for the volunteer to
activate. By sitting he or she will
activate the pressure sensor. This
would simulate a child sitting in a
rear or safety seat.
Labview simulation software will
A microcontroller will be used to
be run in order to implement all
implement the software created by the logic necessary to run the
the DFM development team. The
DFM system. Rather than have the
Microcontroller/CPU controller will interface with all the sensors wired into a
hardware and run the analysis
microcontroller, they will
algorithms to evaluate the state of interface with the underlying
possible passengers.
software using an input/output
device known as a DAQ.
Gonzales 02/25/08
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.
11
A switch will be added to the set
of hardware, but the logical
implementation will not be as
elaborate.
A receiver will be placed in the car
with the generator as a key fob.
The same implementation will
Infrared
When the generator goes out of
take place, but the generator will
Reciever/Transmitter
range (20ft.), the car’s alarm will
not be in the form of a key fob.
sound.
Alarm
The alarm will be implemented by
whatever means the car
manufacturer would like. It is
strongly suggested that the car’s
built in horn or alarm system be
used given the public’s familiarity
to car alarms and what they entail.
A small speaker will be used to
generate noise and indicate the
alarm. A car alarm will not be
necessary to demonstrate.
Microphone
A simple microphone will be
integrated into the DFM system at
the middle rear section of the
vehicle behind the seat. The
microphone will merely check the
intensity of noise in the vehicle. In
the event that the noise is above a
predefined decibel level the
microphone will indicate life.
The computer's microphone will
be used in LabVIEW to determine
if the decibel level has reached a
predefined level.
Table 2. Feature comparison between full product and prototype (Fields, Brandon. 2008)
Gonzales 02/25/08
12
2.2 Prototype Functional Description
The DFM system has an automatic activation feature whenever all devices are connected
properly and the LabView is activated. The algorithm tests all the devices attached to it and
validate them. The testing starts from the pulse sensor down to the microphone. If there are at
least one or more sensors that are not validated, the algorithm will indicate an error after
validation; otherwise, the process will move to the next stage. The next stage is the life detection
process. Figure 3 below shows the diagram of the DFM system activation process.
Figure 3. The DFM system activation algorithm (Fields, Brandon. 2008)
Gonzales 02/25/08
13
The DFM system has also a life detection system. All the sensors namely the pulse,
motion, pressure, microphone, and c02 sensors shall detect life if present. If some sensors did
not detect life, they should loop back to the checking stage. First, the pulse sensor will check the
pulse in the human finger and shall detect pulse rhythm. Once it detects pulse rhythm, the
algorithm shall add a priority value of four and then add the value to the detection variable. The
detection variable is initialized to zero and will keep accumulating the values received from the
sensors until it reaches greater than five. Second, the motion sensor will check any vibrations in
the environment. If vibration is detected, the algorithm shall add a priority value of three and
then add the value to the existing value in the detection variable. Third, the c02 sensor will be
simulated. DFM Inc will assume that simulated c02 sensor will have a Boolean value of true,
when life is detected; otherwise, it will have a Boolean value of false. When c02 returns true, the
algorithm shall add a priority value of three and then add the value to the existing value in the
detection variable. Fourth, the pressure sensor will check when pressure is applied to it. If the
pressure amount is determined, the algorithm shall add a priority value of two and then add the
value to the existing value in the detection variable. Lastly, the microphone will check any
sound in the environment. If a right amount of decibels is determined, the algorithm shall add a
priority value of one and then add the value to the existing value in the detection variable. Once
the accumulated value in the detection variable reaches greater than five, the output from the life
detection algorithm shall indicate a value of true. In addition to the sensors mentioned above, the
temperature sensor and the speaker alarm will also be validated.
Gonzales 02/25/08
Figure 4. The DFM system life detection algorithm (Fields, Brandon. 2008)
2.3 External Interfaces
The external interfaces of the DFM system include all the hardware, software, and user
interface of the prototype.
2.3.1 Hardware Interfaces
14
Gonzales 02/25/08
15
1. Data Acquisition Device: The specific model used in the prototype is the USB-6009. It
has 14-bit input resolution, 12-bit output resolution, and two true analog outputs for
accurate signal (National Instruments Corporation, 2008). It is compatible with the
LabView software and can run on most operating systems.
Figure 5. USB-6009 data acquisition device
2. Pulse Oximeter: Consists of a light-emitting diode (LED) that measures the amount of
oxygen in blood. It registers the pulse within the area between the capillaries and
arteries. This prototype device will act as the heartbeat sensor of the DFM system real
world product.
Figure 6. Pulse oximeter sensor
3. Motion Sensor: It senses physical movement within a specified area. The set comes with
a transmitter and a receiver. The transmitter has a bandwidth of 5KHz (Kilohertz) at
100dB (Decibels). The sound pressure level in the transmitter is 112dB at 40KHz. The
receiver has a bandwidth of 5KHz at –75dB. The sensitivity of the receiver is 67dB at
40KHz (Jameco Electronics, 2008).
Gonzales 02/25/08
16
Figure 7. Ultrasonic motion sensor
4. Pressure Sensor: The specific pressure sensor that is used in the prototype is the 10 kPa
uncompensated silicon pressure sensor. It records the amount of pressure applied to it.
The device provides accurate and linear voltage outputs that are directly proportional to
the applied pressure.
Figure 8. Pressure sensor
5. Temperature Sensor: A linear thermistor sensor measuring air temperature. The specific
model that is used in the prototype is OL-706. It is covered with plastic housing to
protect the thermistor sensor. The cable is insulated and jacketed. DFM Inc chose this
kind of temperature sensor due to its accuracy in nature.
Figure 9. Linear thermistor air temperature
6. Infrared Transmitter: It transmits a 40KHz infrared signal from six to eight feet in
distance. Transmitter size measures 1 inch in length and 0.8 inch in width. This
Gonzales 02/25/08
17
prototype device acts as the transmitter in the key fob of the DFM system real world
product.
Figure 10. Infrared transmitter
7. Infrared Receiver: It will only receive 40KHz of infrared signal. Receiver size is
approximately 1.4 inches in length and 1.2 inches in width. This prototype device acts as
the main controller receiver of the DFM system real world product.
Figure 11. Infrared receiver
8. Laptop Computer: It has the all the software needed for the prototype, namely the
LabView, Notepad, Audio files, etc.
9. Speaker Alarm: It is the regular speaker of the laptop.
Figure 12. Laptop speaker
Gonzales 02/25/08
18
2.3.2 Software Interfaces
LabView is powerful software and flexible instrument commonly used for data analysis.
It has a GUI that develops scalable testing, controls, and measurement applications. It is
capable of gathering data from different kinds of data acquisition devices or instruments.
The language used in this software is G or graphical programming language that is composed
of many nodes wired together. The DFM system algorithm will be coded in this software.
Figure 13. Laboratory virtual instrumentation engineering workbench software
2.3.3 User Interfaces
The DFM system prototype user interface is the GUI of the LabView. It allows manual
adjustments for the input in case some sensors go wrong. The LabView is also scalable for other
new sensors.
2.3.4 Communication Protocols and Interfaces
There are no communication protocols and interfaces in the DFM system.
Gonzales 02/25/08
19
3 Specific Requirements
This section contains detailed functional and performance requirements of the prototype.
It is broke down into subcategories for more precise details.
3.1 Functional Requirements
The functional requirements describe the functions of the DFM system sensors, algorithm,
and other devices. The functional requirements shall be met in order for the prototype to reach
its objectives.
3.1.1 Sensors Functions
Sensors shall meet the following functional requirements:
1. Pulse oximeter, motion sensor, pressure sensor, microphone, and c02 sensor shall return
their assigned priority values, or no value. If a sensor does not return any value, then it
means no life is detected; however, if a sensor returns its assigned priority value, then it
means life is detected.
2. The temperature detector that detects weather conditions and the five sensors (pulse
oximeter, motion sensor, pressure sensor, microphone, and c02 sensors) that detect life,
are the two main factors of the preliminary action. If the sensors detect life and the
temperature detector records a temperature of less than 30 °F or more than 90 °F in at
least 10 seconds, then the algorithm will trigger the laptop speaker sound, an alarm.
3. Pulse sensor shall determine pulse rhythm in the finger. It will not produce pulse
rhythmic data when it is attached to non-living things.
Gonzales 02/25/08
20
4. Motion sensor shall fluctuate the vibration rate when movement is applied; otherwise, the
reading should be stable.
5. Pressure sensor shall increase the reading rate when pressure is applied; otherwise, the
reading should be at its initial stage.
6. Microphone will determine any sounds in the environment; otherwise, the reading should
be at its initial stage.
7. Simulated c02 sensor shall determine life using its predefined value.
3.1.2 Algorithm Functions
Algorithm in the LabView software shall meet the following functional requirements:
1. Algorithm shall validate all sensors before initiating the life detection process.
2. Algorithm shall assign the priority values to all sensors using Table 1 and get the sum of
the values of all sensors that detect life.
3. Algorithm shall activate the laptop speaker by producing a noise if the sum of the priority
values of all sensors is greater than five.
3.1.3 Transmitter and Receiver Functions
Transmitter and receiver shall meet the following functional requirements:
1. Transmitter will keep sending signal to the receiver.
2. Receiver will detect the transmitter within its perimeter range.
3. Receiver will light up when transmitter is detected.
3.2 Performance Requirements
Gonzales 02/25/08
21
The performance requirements describe the performance of the DFM system sensors and
algorithm, and other devices. The functional requirements shall be met in order for the prototype
to reach its objectives.
3.2.1 Sensors Performance
Sensors shall meet the following performance requirements:
1. Temperature detector shall be capable of producing an exact reading within 10 seconds
when it is submerged in hot water with a temperature of 90 °F or above and in cold water
with a temperature of 30 °F or below.
2. The receiver shall have a capability of detecting the transmitter within its range of five
feet. The LED will light up if range is beyond five feet to indicate that the transmitter is
out of range.
3. Temperature detector returns a true value if temperature reading is less than 30 °F or
more than 90 °F.
4. Pressure sensor will be capable of determining pressure of at least 1 PSI.
5. Motion sensor will be capable of determining vibration of more than
40dB.
6. Pulse oximeter will be capable of determining finger pulse of 60-150bpm (beats per
minute).
7. Microphone will be capable of determining sound of more than 10 dB.
3.2.2 Algorithm Performance
LabView will meet the following performance requirements:
1. LabView will be capable of gathering data from sensors without any data collisions.
2. LabView will be capable of updating data received from sensors every few milliseconds.
Gonzales 02/25/08
22
3.2.3 Transmitter and Receiver Performance
Transmitter and receiver will meet the following performance requirements:
1. Transmitter will be capable of sending a signal to the receiver every few milliseconds.
2. Receiver is capable of detecting the transmitter within at least five feet.
3.3 Assumptions and Constraints
DFM Inc considers some assumptions, constraints, and dependencies for the prototype
demonstration. Table 3 below shows the different kinds of conditions and effects on the
requirements.
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.
Prototype distinguishes between
Assumption 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
Varied clothing affects effectiveness of
Assumption
for the weather.
the system.
Reset switch is not used
accidentally or maliciously.
Accidental or malicious use of the reset
Assumption 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
Dependency Prototype cannot be demonstrated
Gonzales 02/25/08
time of demonstration.
PC or laptop with LabVIEW
installed is available at time of
demonstration.
23
without input from the sensors.
Dependency
Prototype cannot be demonstrated
without the LabVIEW software.
Table 3. The DFM system assumptions, constraints, and dependencies (Markham, 2008)
3.2.1 Assumptions
DFM Inc has at least six assumptions. First, DFM Inc will assume that 30° Fahrenheit
will be the coolest temperature. In accordance to that, DFM Inc will bring a cooling device to
obtain that temperature. Second, the hottest temperature will be 90° Fahrenheit, in which the
DFM Inc will also bring a heating device to obtain that temperature. Third, once pressure is
applied to the pressure sensor, DFM Inc will assume that occupant is present. Fourth, since
medical condition may affect pulse reading, DFM Inc will assume that the occupant is in normal
medical condition. Fifth, DFM Inc will assume that the occupant is dressed appropriately for
normal weather. If not dressed appropriately, it will affect the effectiveness of the DFM system
(e.g. The occupant is not dressed appropriately in a very cold weather, it can affect the
predefined lowest temperature limit of the DFM system, since the occupant will not longer be in
danger.). Last, DFM Inc will assume that the reset switch is free from accidental error usage.
Accidental use of the reset switch may affect the data flow of the algorithm.
3.2.2 Constraints
DFM Inc has at least three constraints to consider. First, DFM Inc will simulate the c02
sensor. The LabView software will simulate C02 reading. Second, instead of demonstrating
using a heartbeat sensor, DFM Inc will instead use a pulse oximiter to read a heartbeat rate.
Last, prediction of weather temperature is not supported by DFM Inc.
Gonzales 02/25/08
24
3.2.3 Dependencies
DFM Inc is dependent on all of the sensors, so all of the sensors are very essential to the
prototype demonstration. Even a single sensor that is not working properly will affect the entire
demonstration. Another dependency is that LabView should already be installed on the laptop
computer. Without LabView, input from sensors will not be processed.
3.3 Non-Functional Requirements
Non-functional requirements of the DFM system include the security, maintainability, and
reliability of the prototype.
3.3.1 Security
The DFM system algorithm is protected to ensure that non-group members are restricted
to edit the source code. Only group members have the privileges to add or edit the algorithm’s
source code.
3.3.2 Maintainability
All sensors and the algorithm must be tested and maintained before DFM Inc uses them.
Regular testing of the sensors can help determine the current quality of the sensors. DFM Inc
must also make sure that the wirings are not tangled all over the prototype, which can cause a
false reading. Unnecessary plug-ins or wirings must be removed. Making the prototype simple
and well organized can reduce prototype failures.
3.3.3 Reliability
Gonzales 02/25/08
25
The end product has an automatic start, which guarantees the system will start every time
the driver starts the vehicle. The DFM system is wired to the vehicles battery for energy source.
In case the DFM system fails to initiate, there will be a warning message located on the
dashboard of the vehicle that indicates system failure. The vehicle owner must then take the
vehicle to an auto shop for repair.
4 Appendix
DFM Inc formal resource request document is needed for building the DFM system
prototype.
4.1 Formal Resource Request Document (DFM Inc, 2008)
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 XYZ product:
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
Linerar Thermistor Air
Temperature
Pulse Oximeter
Price
Qty Ea
2
$7.95
2
$8.99
2 $24.95
Part #
136654
218827
177092
Company
Jameco.com
Jameco.com
Jameco.com
OL-706
Omega.com
1
$61.00
$68.00
FitnessEquipment
2
$19.99
$39.98
http://www.fitnessequipment.com/acatalog/
Online_Catalog_Pulse_Monitor_
_Ear_Clip_
P-703A
Total
$15.90
$19.98
$49.90
Gonzales 02/25/08
for_Pulse_Monitor_1034.html
USB-6009 Kit (LabVIEW and
DAQ)
77932022
NI.com
2
$159.00
$331.62
Software Purchase (list all items required for purchase):
Part Description
FRAPS - Real-time video
render software
Part #
Price
Company Qty Ea
N/A
Fraps.com
1
$37.00
Total
$37.00
The following University resources are required to support the prototype development and
demonstration:
1. Laptop/ Second computer
a. It will be used to display the interaction of hardware element and the
algorithm processes during the live prototype demonstration.
b. Windows XP with connection to the internet
c. Quantity: 1
d. Date required: March 1, 2008
e. Deliver to: Don’t Forget Me Inc.
2. LabVIEW installed on the Laptop
a. LabVIEW is the primary software component used in the project.
Through it the development team will interact with the hardware and
control the system algorithms.
b. LabVIEW must have the drivers installed for the DAQ used in the
prototype, a USB-6009.
c. Quantity 1
d. Date required: March 1, 2008
e. Deliver to: Don’t Forget Me Inc.
26
Download