Lab 5 – Don’t Forget Me: SBIR
DFM Inc.
CS411
Janet Brunelle
May 4, 2008
Lab 5 SBIR
Table of Contents
1
Product Description Introduction ................................................................................ 1
1.1
Product Description ............................................................................................ 2
1.1.1
Key Product Features and Capabilities ....................................................... 2
1.1.2
Major Components (Hardware/Software)................................................... 4
1.1.3
Target Market/Customer Base .................................................................... 7
1.2
Product Prototype Description ............................................................................ 8
1.2.1
Prototype Functional Objectives ................................................................. 8
1.2.2
Prototype Architecture ................................................................................ 9
1.2.3
Innovative Features ................................................................................... 12
1.2.4
Challenges and Risks ................................................................................ 13
1.3
Prototype Demonstration Description............................................................... 14
2 Product Specification ................................................................................................ 15
2.1
Product Specification Introduction ................................................................... 15
2.1.1
Purpose...................................................................................................... 16
2.1.2
Scope ......................................................................................................... 19
2.1.3
Definitions, Acronyms, and Abbreviations .............................................. 20
2.1.4
References ................................................................................................. 23
2.1.5
Overview ................................................................................................... 23
2.2
General Description .......................................................................................... 24
2.2.1
Prototype Architecture Description .......................................................... 24
2.2.2
Prototype Functional Description ............................................................. 27
2.2.3
External Interfaces .................................................................................... 32
2.2.3.1 Hardware Interfaces .............................................................................. 32
2.2.3.2 Software Interfaces ............................................................................... 33
2.2.3.3 User Interfaces ...................................................................................... 35
2.2.3.4 Communication Protocols and Interfaces ............................................. 36
2.3
Specific Requirements ...................................................................................... 36
2.3.1
Functional Requirements .......................................................................... 36
2.3.1.1 DFM System Activation Process .......................................................... 36
2.3.1.2 Sensor Overview ................................................................................... 37
2.3.1.2.1 Life Detection Sensors .................................................................... 37
2.3.1.2.2 Environmental Sensor ..................................................................... 38
2.3.1.3 Life Detection Procedures..................................................................... 38
2.3.1.4 Environment Evaluation Procedures..................................................... 39
2.3.1.5 Transmitter and Receiver Functions ..................................................... 39
2.3.1.6 Alarm System........................................................................................ 40
2.3.1.7 Reset Procedures ................................................................................... 41
2.3.1.8 LabVIEW Setup .................................................................................... 42
2.3.1.9 Simulation Procedures .......................................................................... 42
2.3.2
Performance Requirements ....................................................................... 43
2.3.2.9 DFM System Activation ....................................................................... 43
2.3.2.10
Life Detection ................................................................................... 43
ii
Lab 5 SBIR
2.3.2.10.1 Sensor Performance ...................................................................... 43
2.3.2.10.2 Procedure Performance ................................................................. 44
2.3.2.11
Environmental ................................................................................... 44
2.3.2.11.1 Sensor Performance ...................................................................... 45
2.3.2.11.2 Procedure Performance ................................................................. 45
2.3.2.12
Transmitter and Receiver Functions ................................................. 46
2.3.3
Assumptions and Constraints .................................................................... 46
2.3.3.1 Assumptions.......................................................................................... 47
2.3.3.2 Constraints ............................................................................................ 49
2.3.3.3 Dependencies ........................................................................................ 50
2.3.4
Non-Functional Requirements .................................................................. 51
2.3.4.1 Security ................................................................................................. 51
2.3.4.2 Maintainability ...................................................................................... 51
2.3.4.3 Reliability.............................................................................................. 52
3 Test Plan.................................................................................................................... 52
3.1
Test Plan Objectives ......................................................................................... 52
3.2
Test Plan............................................................................................................ 55
3.2.1
Testing Approach ...................................................................................... 55
3.2.2
Identification of Tests ............................................................................... 59
3.2.3
Test Schedule ............................................................................................ 60
3.2.4
Fault Reporting and Data Recording ........................................................ 61
3.2.5
Resource Requirements ............................................................................ 61
3.2.6
Test Environment ...................................................................................... 62
3.2.7
Test Responsibilities ................................................................................. 63
3.3
Test Procedures ................................................................................................. 63
3.3.1
Test Case Names and Identifiers............................................................... 64
Traceability to Requirements ............................................................................................ 72
4 User Manual .............................................................................................................. 74
4.1
Introduction (David) ......................................................................................... 74
4.2
Product Overview (David) ................................................................................ 75
4.3
Getting Started (David) ..................................................................................... 75
4.3.1
Hardware ................................................................................................... 76
4.3.2
Software .................................................................................................... 78
4.4
Prototype Procedures (Hernan) ......................................................................... 78
4.4.1
Initialization Procedure ............................................................................. 79
4.4.2
Activation Procedure ................................................................................ 82
4.4.3
The Running State..................................................................................... 83
4.4.4
Termination Procedure.............................................................................. 86
4.5
Product Features (Daniel) ................................................................................. 87
4.5.1
DFM Virtual Instrument (VI) GUI ........................................................... 89
4.5.2
Motion Sensor ........................................................................................... 91
4.6
Error Messages (Brandon) ................................................................................ 93
4.6.1
Errors by message ..................................................................................... 94
4.6.2
Errors by action number............................................................................ 95
4.7
Troubleshooting (Brandon) ............................................................................... 96
5 Lessons Learned ........................................................................................................ 99
iii
Lab 5 SBIR
6
Appendix ................................................................................................................. 100
List of Figures
Figure 1. Major functional component diagram ................................................................ 5
Figure 2. Phase 1 prototype major functional component diagram................................. 10
Figure 3. Major Functional Component Diagram ........................................................... 17
Figure 4. Prototype Major Functional Component Diagram........................................... 25
Figure 5. DFM Algorithm Flowchart ............................................................................. 28
Figure 6. DFM Activation Flowchart ............................................................................. 30
Figure 7. DFM Life Detection Algorithm ...................................................................... 31
Figure 8. Environmenal Sensor ...................................................................................... 32
Figure 9. Life Detection Sensors .................................................................................... 33
Figure 10. Alarm VI Front Panel display ....................................................................... 34
Figure 11. Alarm VI Block Diagram .............................................................................. 35
Figure 12. Phase 1 prototype major functional component diagram................................ 56
Figure 13. Presentation room layout ............................................................................... 62
Figure 14. DFM system project box ................................................................................. 76
Figure 15. DFM system project box interior .................................................................... 77
Figure 16. The DFM system VI simulated signal ............................................................ 79
Figure 17. The DFM system VI real sensor signal ........................................................... 80
Figure 18. The DFM system VI force on signal ............................................................... 80
Figure 19. The DFM system VI force off signal ............................................................. 81
Figure 20. The DFM system VI disable signal................................................................. 81
Figure 21. LabView run button ........................................................................................ 82
Figure 22. DFM system Danger Level indicator .............................................................. 82
Figure 23. The DFM system VI reset button (light off). .................................................. 83
Figure 24. The DFM system VI microphone graph example.......................................... 84
Figure 25. The DFM system VI life detection sensors light indicators............................ 84
Figure 26. The DFM system VI temperature sensor and key fob ................................... 85
Figure 27. The DFM system VI preempt switch .............................................................. 85
Figure 28. LabView pause button .................................................................................... 86
Figure 29. LabView stop button ...................................................................................... 86
Figure 30. The DFM system VI reset button (light on). .................................................. 87
Figure 31. DFM system prototype major functional component diagram ....................... 88
Figure 32. Environmental sensor for the DFM system .................................................... 88
Figure 33. Occupancy detection sensors for the DFM system ......................................... 89
List of Tables
Table 1. Sensor priorities .................................................................................................... 3
Table 2. Feature comparison between full product and prototype.................................... 12
Table 3. Sensor priorities .................................................................................................. 18
Table 4. Feature comparison between full product and prototype.................................... 27
iv
Lab 5 SBIR
Table 5. Effects of Assumptions, Dependencies, and Constraints on Requirements ....... 47
Table 6. DFM system prototype test cases by category.................................................... 60
Table 7. DFM system prototype test schedule .................................................................. 61
Table 8, Traceability to requirements table ...................................................................... 74
Table 9. Error Messages ................................................................................................... 94
v
Lab 5 SBIR
1 Product Description Introduction
Last year at least 43 children died in cars while their parent or caregiver was
away, and each year the number of deaths increases (KAC, 2007). Unfortunately, it does
not take long for a car to become dangerously hot and endanger the life of a child inside.
As of now, modern cars do not have the capability to determine when the conditions of
its interior could pose a danger to its passengers, nor do many vehicles have the ability to
register that a child has been left inside.
The goal of the Don't Forget Me (DFM) system is to eliminate such instances of
unintentional child endangerment. By implementing a series of sensors that will
determine if a vehicle is occupied, the system can immediately take corrective action. A
heartbeat sensing system is one of the primary components; the data it collects is
analyzed for a verifiable pattern. Secondly, pressure sensors will be installed beneath the
seats to determine if anyone is occupying the vehicles. Once again, the output of the
sensors will be checked by the accompanying software to ensure it is a person and not an
obstruction that has been detected. A microphone will be implemented to monitor for
loud noises which will help determine if the vehicle is occupied. There will also be
careful monitoring of the temperature, motion, and CO2 inside the car. Since the
temperature can rise to fatal levels in minutes, a high temperature reading will initiate an
aggressive check of the vehicle for persons who may be in danger.
When inputs from all the sensors collectively indicate that the vehicle is occupied,
the vehicles alarm system will be initiated. Also, the driver’s key fob attachment will
begin to vibrate to indicate that the alarm system has been activated. This device is
1
Lab 5 SBIR
autonomous and does not require the activation of the car's operator. It seeks to eliminate
instances when one can let even important issues pass their attention.
1.1 Product Description
This section describes in detail the manner in which the fully implemented DFM
safety system will run. Specifically, this section describes the sensors used in the system,
and the key fob’s manner of interacting with the system. A breakdown of the product,
the intended customer, and reliability are presented in this section.
1.1.1 Key Product Features and Capabilities
The DFM safety system is unique because it utilizes an assortment of sensors to
detect life in a manner that has never before been implemented. While two or more
sensors may be sufficient to detect life, more would be necessary to reach a high degree
of certainty. Each sensor allows the software to incorporate a system of checks and
balances to prevent false alarms or decisions made from insufficient data. Likewise, the
system will not be rendered useless when one sensor inevitably malfunctions (given the
lifespan of any component in a vehicle over an extended period of time).
Overall, the greatest strength of the DFM system is the software developed to
integrate each hardware component into one homogenous system. Under the assumption
that no two types of sensors have the same accuracy, neither will they have the same
priority. While a motion sensor is effective at detecting movement, it would not have the
same accuracy as a heartbeat sensor meant to analyze a heart’s rhythm; therefore it is
prudent to grant a positive reading from the heartbeat sensor higher priority than the
result from a motion sensor. A CO2 sensor is even less indicative of life given that the
car is not airtight and the sensor may have a low level of precision. As a result, the DFM
2
Lab 5 SBIR
system must take each of the sensor’s results into a priority based system where each
sensor is capable of generating a positive result for life detection independently of the
others.
Sensor Priority Value
Pulse Sensor
4
Motion Sensor
3
3
CO2 Sensor
Pressure Sensor
2
Microphone
1
Table 1. Sensor priorities
Table 1 indicates the specific priorities for the DFM system. In order for life to
be detected with a high level of certainty the sum of the values must be greater than five.
The specific values were designated based on the combination of sensor that would be
needed to give a positive reading for the alarm to be initiated. For example, the pulse
sensor and any of the three beneath it in the table will cause the alarm to go off.
Likewise, the CO2 and the pressure sensor would not be high enough in priority to initiate
the alarm, but if the microphone was also getting a positive reading the system
acknowledge the presence of life.
The process of prioritizing the sensor’s results allows the DFM system to
correctly indicate the presence of life even if some of the sensors are generating false
results. In the same manner that shareholders have proportional control of a company,
each sensor will have a degree of influence over the system, which is determined by its
3
Lab 5 SBIR
accuracy. The software will take into account the different values of influence and
certainty generated by sensor data and make an educated decision whether to act.
1.1.2 Major Components (Hardware/Software)
Figure 1 illustrates the major functional components of the DFM system. It can
be split up into three discrete units, the sensor array, the logic controller, and the human
interface devices. In the diagram, the sensor array consists of all the devices depicted
above the CPU, the logic controller is depicted in the box labeled as the CPU, and all of
the human interface devices are depicted below the CPU.
4
Lab 5 SBIR
Figure 1. Major functional component diagram
The sensor array is the most notable portion of the DFM system. Each sensor
gives the logic controller independent data. The sensors attempt to assess the
environment in the car to determine if a person is present and if the vehicle is
approaching a dangerous state. Individually each sensor is not a significant addition to a
vehicle; however, nor is any individual sensor capable of making an accurate assessment
5
Lab 5 SBIR
of the vehicle’s occupancy. Together all the sensor are used to give the CPU a reliable
representation of the environment inside the vehicle.
The logic controller is the element of the DFM system that puts all of the sensor’s
data to work. Through the logic controller, data is received from the sensors and the
remote detector device to determine the location of the driver and the state of the vehicle.
The logic controller implements all the software and consists primarily of the
microcontroller.
Lastly, the interface devices are the remote detector, the transmitter device, and
the reset switch. Theses devices allow for the driver to have minimal interaction with the
DFM system. Since the DFM system is supposed to run autonomously, it would only
hurt the integrity of the system to allow the end user too much interaction. Interaction
with the DFM system is therefore limited to the driver carrying the transmitter device and
using the reset switch in case of a false alarm.
The entire system will be installed as inconspicuously as possible. Few
components should be visible to the passengers with the exception of the aforementioned
reset switch, and they key fob device. While installations will vary based on the car
manufacturer’s needs and design limitations there will be aspect of the installation that
will remain constant. First of all, the reset switch will be in the back of the vehicle
behind the middle seat (the typical location of a car safety seat). Likewise, the
accelerometer sensor(s) will be installed inside the same seat as safety seat would be
placed according to the law. Secondly, the temperature sensor, CO2, and microphone can
be placed anywhere on the interior of the vehicle as long as they would not come into
casual contact with a passenger. Third, the pressure sensor, and the motion sensor will be
6
Lab 5 SBIR
placed so that they can most accurately assess the life of an infant in a car safety seat.
Therefore, the motion sensor would be placed on the ceiling of the vehicle facing
downward and directed toward the rear middle seat with the line of sight including the
entire row of seats. Similarly, the pressure sensors will be installed beneath the rear row
of seat cushions. Lastly, the CPU and the transmitter device will be installed anywhere in
the vehicle’s interior the manufacturer desires. Ideally, the two devices will be installed
in a location that allows for easy maintenance and best signal interaction with the driver’s
key fob. Overall, the system will not be readily apparent to passengers; however, the
driver will be aware of the diagnostic light at the front of the vehicle and reset switch at
the rear of the vehicle.
1.1.3 Target Market/Customer Base
The DFM system will be marketed as a license to manufacture vehicles with the
patented technology, as well as software to run on a suggested set of hardware. Also,
validation documentation and software will be provided to the customer to ensure the
system can guarantee the highest degree of safety. Automobile manufacturers will be the
primary customer of the DFM system; car buyers will be the secondary customers
because they will be using the product.
In order to ensure that the product will be affordable to the average car owner; the
car manufacturers will install, and purchase or manufacture the hardware. The
manufacturer will be able to keep production costs low by installing and manufacturing
the hardware in house, rather than buying a preassembled system. Likewise, they will
not have to buy a different version of the DFM for each model of car it is to be installed
in. The manufacturer can take the core software and microcontroller and incorporate it
7
Lab 5 SBIR
into their designs. Lastly, if the customer decides that they do not want to implement the
DFM system with all of the recommended sensors, they can decide to leave one or two
out and set the configurations in the software provided to them accordingly. This method
puts most of the design control in the manufacturer’s hands and allows the developers to
focus on successful validation and enhancements, rather than manufacturing processes.
1.2 Product Prototype Description
This section addresses a minimalist implementation of the DFM system by
reducing the complexity of the software used. The prototype will be demonstrated in
front of a review panel in order to evaluate its effectiveness. Due to time and budgetary
constraints, many aspects of the systems were reduced to ensure that a working prototype
will be completed.
1.2.1 Prototype Functional Objectives
The objectives of the prototype are to show that the DFM system can in fact
determine if a human is present, if the environment will become hazardous, if the driver
is close enough to provide assistance, and ensure that customer is satisfied with the
product. The sensors can test if a human is present by providing data to the LabVIEW
(Laboratory Virtual Instrumentation Engineering Workbench) software where each
sensor can independently evaluate the vehicle. If the certainty is high over the majority
of the sensors, a person will be assumed present. The sensor priority can be tested by
setting off each sensor alone or in different combinations to determine if the algorithm is
effective.
8
Lab 5 SBIR
Next, the environment is deemed hazardous if the temperature is rising or falling
at a rate that would become harmful. Not only is the current temperature taken into
account, but also the past temperatures. This way, the DFM can set off the alarm even if
danger is still minutes away. The system would be very ineffective if it sounds an alarm
only when the environment is deadly, or even if the driver is too far gone to ameliorate
the situation.
Lastly, the prototype will show that a driver’s distance from the car is being
monitored by the DFM system. If the driver goes further than 20ft from the car the alarm
will sound regardless of the temperature in the car. Likewise, despite the driver’s
distance from the car, the alarm will sound if the temperature reached a fatal level. What
is most important is any person or child left in the car when the alarm sounds is removed
before the system is reset, which is why the reset is positioned in the rear center of the
vehicle. After demonstrating the full functionality of the DFM system the customer will
realize the potential of the system and attain a greater understanding of the power and
functionality of the DFM system.
1.2.2 Prototype Architecture
The physical architecture of the prototype is focused around the LabVIEW
simulation software. LabVIEW makes it possible to interact with an array of sensors by
wiring them into the data acquisition device (DAQ). Once properly wired, the LabVIEW
software can be used interact with the ports on the DAQ. Therefore, the LabVIEW
software and the laptop take the place of the CPU. This removes the difficult task of
creating the physical implementation of the DFM system from their constituent
9
Lab 5 SBIR
components alone. Likewise, the algorithm can be programmed and tested without
wasting time and money programming into a microcontroller.
Figure 2. Phase 1 prototype major functional component diagram
Figure 2 illustrates the major functional components of the DFM system
prototype and the interaction of its components. Table 1 elaborates on the reductions that
will take place in order to complete the prototype. Unlike the real-world implementation
10
Lab 5 SBIR
of the DFM system, there will be no microcontroller for the system to be installed on;
rather, all of the software will be run through LabVIEW. While the microcontroller
would allow the DFM system to run without a dedicated computer, it would not be
flexible enough to create a very low scale prototype. Likewise, using a microcontroller
rather than simulation software would make it more difficult to test each component in
the DFM system.
Features
Real World Project
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.
A pulse oximeter will be attached
to a volunteer’s finger. This
device will give the same input
values of the accelerometer, but
will require the volunteer to attach
the device. Likewise, the presence
of a pulse will be the only criteria,
not rhythm.
CO2 Sensor
The sensor will measure the level of CO2 No CO2 sensor will be used for the
in the vehicle. A steady increase will
prototype; rather, the sensor will be
indicate there is no ventilation and
simulated in LabVIEW.
human or animal is present.
Temperature Sensor The temperature sensor will read in very
precise values to determine 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 The motion sensor will read in
from the motion sensor over time to
several values over a short time
determine if the readings may be
period. If motion is detected over
influenced by a person. An instance of that time period, then the software
motion without life would be the
will assert that a person is present.
movement of the vehicle’s air
conditioning vents.
Pressure Sensor
Like the motion sensor the values given The sensor will be placed under a
to the software will be used to determine cushion for the volunteer to sit on.
if there is not a pattern that could indicate By sitting he or she will activate
life. This would mitigate false alarms
the pressure sensor. This would
due to devices that could trigger the
simulate a child sitting in a rear or
sensor, such as a child’s mechanical toy. safety seat.
11
Lab 5 SBIR
Features
Real World Project
Prototype
Microcontroller/CPU A microcontroller will be used to
implement the software created by the
DFM development team. The controller
will interface with all the hardware and
run the analysis algorithms to evaluate
the state of possible passengers.
Labview simulation software will
be run in order to implement all the
logic necessary to run the DFM
system. Rather than have the
sensors wired into a
microcontroller, they will interface
with the underlying software using
an input/output device known as a
DAQ.
Reset Switch
A switch will be added to the set of
hardware, but the logical
implementation will not be as
elaborate.
A switch will be placed in rear of the
vehicle so that the driver can manually
shut off the device in case of a false
alarm. The switch will time out if the
system still indicates danger and when
the car is restarted.
Radio Frequency
A receiver will be placed in the car with The same implementation will take
Reciever/Generator the generator as a key fob. When the
place, but the generator will not be
generator goes out of range (20ft.), the in the form of a key fob.
car’s alarm will sound.
Alarm
The alarm will be implemented by
whatever means the car manufacturer
would like. It is strongly suggested that
the car’s built in horn or alarm system be
used given the public’s familiarity to car
alarms and what they entail.
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
1.2.3 Innovative Features
12
Lab 5 SBIR
The DFM system is innovative because it is the first device to incorporate a series
of environmental sensors in order to determine the presence of life. By giving each of the
sensors a different level of importance, the software will determine the severity of the
situation and calculate a level of certainty that a person is in danger. While safety
features are added to cars each year, few actually attempt to mitigate vehicular
hyperthermia. The DFM system will take into account the temperature, both highs and
lows, as well as the location of the driver to determine if there is an occupant and whether
he or she is in danger. By using extensively tested algorithms, the DFM system will be
able to sound an alarm with a high degree of certainty of imminent danger.
1.2.4 Challenges and Risks
Currently, the greatest risks for the project are lack of customer buy in, product
malfunctions, and caregivers becoming complacent. In the DFM system’s current state, a
prototype is being developed to encourage customers to buy licenses. The current cost
for one license of the DFM system is $100. The license allows the manufacturer to use
the patent and gives them the right to use the developed software. If the customer is
uninterested in the product, has found a company that can do a better job under a
different patent, or is unable to afford the licensing fee, there is very little that can be
done to save the DFM system. These three factors are the greatest risk, and can only be
mitigated by keeping the price competitive and creating a product that is top of the line.
Secondly, a more serious concern is the malfunction of the hardware resulting in
death. Death is always going to be an issue, but it is being mitigated by creating an
assembly of sensors that can be used to check for errors in the other’s readings.
Likewise, extensive testing will go on to ensure that the DFM system has a high success
13
Lab 5 SBIR
rate. Through testing, errors can be found and mitigated until the product has been
significantly improved.
Lastly, complacency is one of the hardest risks to reduce because it comes from
too much faith in the product. The best way to reduce complacency is to require some
interaction with the caregiver over designated intervals of time. This way, the caregiver
is reminded of the device’s need for human involvement and they will be less likely to
take for granted the automated nature of the system.
1.3 Prototype Demonstration Description
The DFM system prototype demonstration will require a laptop computer, a copy
of Labview simulation software, a DAQ, a small speaker, a radio frequency generator, a
radio frequency receiver, a spring-loaded switch, a pulse oximeter, a temperature sensor,
a pressure sensor, and a motion sensor. A chair made to resemble the seat of a car will be
placed in front of the review panel. A pulse oximeter will also be placed in the chair,
while the pressure sensor is placed beneath the chair. The motion sensor will be directed
toward the chair, no more than three feet away. Lastly, a temperature sensor will be
placed on the table next to a heating element and a bucket of ice. Each of the sensors
already connected to the DAQ will then output their readings into LabVIEW.
First the LabVIEW software will run through the simulation without anyone to
influence the sensors, will indicate a run where no passenger is present in the car. The
temperature sensor will be placed in the bucket of ice to display temperature warning on
the screen followed by exposure to the heating element which should yield another
warning. Despite the extreme environments, the DFM system will register no passengers
and not set off the alarm.
14
Lab 5 SBIR
In order to demonstrate a child left inside of a vehicle, a volunteer from the
development team will sit in the demonstration seat. The sensor readings should be
visible to the panel at all times. Both the pressure sensor and the motion sensor should
indicate life. The volunteer will place the pulse oximeter around their finger so that the
software will be able to register a human pulse. Lastly, the temperature sensor will be
exposed to the hot and cold environments separately, each time setting off the alarm as
the temperature values exceed predefined thresholds.
As for the radio frequency generator and the radio frequency receiver, another
volunteer will take the generator away from the receiver, which will result in a decrease
in signal intensity. The alarm will go off when the intensity decreases to a predefined
value, which is measured experimentally to be ten feet. When the second volunteer
returns, they must reset the device by hand by using the reset switch. After which, the
temperature sensor will once again be exposed to extreme temperature, which will again
setting off the alarm despite the location of the second volunteer.
2 Product Specification
2.1 Product Specification Introduction
Last year, at least 43 children died in cars while their parent or caregiver was
away, and each year the number of related deaths increases (KAC, 2007). Unfortunately,
it does not take long for a car to become dangerously hot and endanger the life of a child
inside. Currently, passenger vehicles do not have the capability to determine when the
conditions of its interior pose a danger to its occupants, nor do vehicles have the ability to
register that a child has been left inside.
15
Lab 5 SBIR
The goal of the Don't Forget Me (DFM) system is to eliminate such instances of
intentional or unintentional child endangerment. By installing a series of sensors along
with software that determine if a vehicle is occupied, the system can immediately take
corrective action. A heartbeat sensing system is one of the primary components; the data
it collects is analyzed for a verifiable pattern. Secondly, pressure sensors installed
beneath the seats determine if anyone is occupying the vehicle. Once again, the outputs
of the sensors are checked by the accompanying software to ensure it is a person and not
an obstruction that is detected. A microphone is implemented to monitor for loud noises
which will help determine if the vehicle is occupied. Temperature, motion, and CO2 are
also constantly monitored inside the car. Since the temperature can rise to fatal levels in
minutes, a high temperature reading initiates an aggressive check of the vehicle for
people in danger.
When inputs from all the sensors collectively indicate that the vehicle is occupied,
the vehicle’s alarm system is initiated. Also, the driver’s key fob attachment will begin
to vibrate to indicate that the alarm system has been activated. This device is
autonomous and does not require the activation of the car's operator. It seeks to eliminate
instances when one can let even important issues pass their attention (Fields, 2008).
2.1.1 Purpose
The DFM safety system is unique because it utilizes an assortment of sensors to
detect life in a manner that has never before been implemented. While two or more
sensors may be sufficient to detect life, more would be necessary to reach a high degree
of certainty. Each sensor allows the software to incorporate a system of checks and
16
Lab 5 SBIR
balances to prevent false alarms or decisions made from insufficient data. Likewise, the
system will not be rendered useless when one sensor inevitably malfunctions, given the
lifespan of any component in a vehicle over an extended period of time.
Figure 3. Major Functional Component Diagram
Overall, the greatest strength of the DFM system is the software developed to
integrate each hardware component into one homogenous system, as depicted in the
Figure 3. Under the assumption that no two types of sensors have the same accuracy,
neither will they have the same priority. While a motion sensor is effective at detecting
movement, it would not have the same accuracy as a heartbeat sensor meant to analyze a
heart’s rhythm; therefore, it is prudent to grant a positive reading from the heartbeat
sensor higher priority than the result from a motion sensor. A CO2 sensor is even less
17
Lab 5 SBIR
indicative of life given that the car is not airtight and the sensor may have a low level of
precision. As a result, the DFM system must take each of the sensors’ results into a
priority based system where each sensor is capable of generating a positive result for life
detection independently of the others.
Life Detection Sensors
Priority Value
4
Pulse Sensor
3
Motion Sensor
3
CO2 Sensor
2
Pressure Sensor
1
Microphone
Table 3. Sensor priorities
Table 3 indicates the specific priorities for the DFM system. In order for life to
be detected with a high level of certainty, the sum of the values must be greater than five.
The specific values were designated based on the combination of sensors that would be
needed to give a positive reading for the alarm to be initiated. For example, the pulse
sensor and any of the three beneath it in the table will cause the alarm to go off.
Likewise, the CO2 and the pressure sensor would not be high enough in priority to initiate
the alarm, but if the microphone was also getting a positive reading, the system would
acknowledge the presence of life.
The process of prioritizing the sensors’ results allows the DFM system to
correctly indicate the presence of life even if some of the sensors are generating false
results. In the same manner that shareholders have proportional control of a company,
each sensor will have a degree of influence over the system, which is determined by its
accuracy. The software will take into account the different values of influence and
18
Lab 5 SBIR
certainty generated by sensor data and make an educated decision whether to act (Fields,
2008).
2.1.2 Scope
The objectives of the prototype are to show that the DFM system can in fact
determine if a human life is present, if the environment has become hazardous, and if the
driver is close enough to provide assistance. The sensors can test if a human is present by
providing data to the LabVIEW (Laboratory Virtual Instrumentation Engineering
Workbench) software where each sensor can independently evaluate conditions inside of
the vehicle. If the certainty is high over the majority of the sensors, a life will be
assumed present. Life detection can be tested by setting off each sensor alone or in
different combinations to determine if the algorithm is effective and appropriate alarms
are activated.
Next, the environment is deemed hazardous if the temperature is rising or falling
at a rate that would become harmful. Not only is the current temperature taken into
account, but also the past temperatures. This way, the DFM system can set off the alarm
even if danger is still minutes away. The system would be very ineffective if it sounds an
alarm only when the environment is deadly, or even if the driver is too far gone to
ameliorate the situation.
Lastly, the prototype shows that a driver’s distance from the car is being
monitored by the DFM system. If the driver goes further than 20ft from the car, the
alarm will sound regardless of the temperature in the car. Likewise, despite the driver’s
distance from the car, the alarm will sound if the temperature or other conditions reached
a fatal level. What is most important is any person or child left in the car when the alarm
19
Lab 5 SBIR
sounds is removed before the system is reset, which is why the reset is positioned in the
rear center of the vehicle (Fields, 2008).
2.1.3 Definitions, Acronyms, and Abbreviations
This section provides definitions and further explanations for terms used in the
document. If a term uses an acronym, it is spelled out in this section. This section is
meant to assist the reader in understanding the terminology used in this document.
Accelerometer: A device that measures the force on a sensor, primarily vibrations.
Variations in the accelerometers readings could be analyzed and 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).
20
Lab 5 SBIR
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.
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.
Microcontroller: A microprocessor that is optimized for self-sufficient systems, usually
runs on low power, and does not require a complex set of hardware.
21
Lab 5 SBIR
Motion sensor: Sensor for detecting movement or motion. This sensor could use radio
frequency or changes in light to detect motion.
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.
22
Lab 5 SBIR
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.
2.1.4 References
Fields, Brandon. (2008). Lab 1 – DFM Product Description. Norfolk, VA: Author.
Kids and Cars. (n.d.). Kids and Cars. Retrieved January 28, 2007, from Kids and Cars
Web site: http://www.kidsandcars.org/.
Oximity. (2002). Principles of Pulse Oximetry Technology. Retrieved January 21, 2007,
from Internet World Stats Web site:
http://www.oximetry.org/pulseox/principles.htm.
2.1.5 Overview
This product specification provides details concerning the hardware and software
design, external interfaces, and the capabilities and features of the DFM system
prototype. The following information describes the implementation of the prototype as
well as aspects of its design and considerations made during testing and demonstration.
Material covered in this document primarily pertains to the prototype of the DFM system.
23
Lab 5 SBIR
2.2 General Description
The DFM system is innovative in its use of simple sensors and the integration of
microcontroller technology in order to add a greater level of safety to modern
automobiles. The greatest strength of the DFM system is the algorithm that prioritizes
each of the sensors in order to determine the likelihood of life and danger. The system
intelligently decides when to act and when danger is not present. Most importantly it
seldom requires any direct interaction with the driver.
2.2.1 Prototype Architecture Description
The physical architecture of the prototype is focused around the LabVIEW
simulation software. LabVIEW makes it possible to interact with an array of sensors by
wiring them into the data acquisition device (DAQ). Once properly wired, the LabVIEW
software can be used interact with the ports on the DAQ. The LabVIEW software and the
laptop take the place of the CPU. Using LabVIEW removes the difficult task of creating
the physical implementation of the DFM system from their constituent components alone.
Likewise, the algorithm can be programmed and tested without wasting time and money
programming into a microcontroller.
(This space intentionally left blank.)
24
Lab 5 SBIR
Figure 4. Prototype Major Functional Component Diagram
Figure 4 illustrates the major functional components of the DFM system
prototype and the interaction of its components. Table 3 elaborates on the reductions that
will take place in order to complete the prototype. Unlike the real-world implementation
of the DFM system, there will be no microcontroller for the system to be installed on;
rather, all of the software will be run through LabVIEW. While the microcontroller
would allow the DFM system to run without a dedicated computer, it would not be
flexible enough to create a very low scale prototype. Likewise, using a microcontroller
rather than simulation software would make it more difficult to test each component in
the DFM system.
(This space intentionally left blank.)
25
Lab 5 SBIR
Features
Real World Project
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.
A pulse oximeter will be attached
to a volunteer’s finger. This
device will give the same input
values of the accelerometer, but
will require the volunteer to attach
the device. Likewise, the presence
of a pulse will be the only criteria,
not rhythm.
CO2 Sensor
The sensor will measure the level of CO2 No CO2 sensor will be used for the
in the vehicle. A steady increase will
prototype; rather, the sensor will be
indicate there is no ventilation and
simulated in LabVIEW.
human or animal is present.
Temperature Sensor The temperature sensor will read in very
precise values to determine 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 The motion sensor will read in
from the motion sensor over time to
several values over a short time
determine if the readings may be
period. If motion is detected over
influenced by a person. An instance of that time period, then the software
motion without life would be the
will assert that a person is present.
movement of the vehicle’s air
conditioning vents.
Pressure Sensor
Like the motion sensor the values given The sensor will be placed under a
to the software will be used to determine cushion for the volunteer to sit on.
if there is not a pattern that could indicate By sitting he or she will activate
life. Determining a pattern would
the pressure sensor, which would
mitigate false alarms due to devices that simulate a child sitting in a rear or
could trigger the sensor, such as a child’s safety seat.
mechanical toy.
Microcontroller/CPU A microcontroller will be used to
implement the software created by the
DFM development team. The controller
will interface with all the hardware and
run the analysis algorithms to evaluate
the state of possible passengers.
26
Labview simulation software will
be run in order to implement all the
logic necessary to run the DFM
system. Rather than have the
sensors wired into a
microcontroller, they will interface
with the underlying software using
an input/output device known as a
DAQ.
Lab 5 SBIR
Features
Reset Switch
Real World Project
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.
Prototype
A switch will be added to the set of
hardware, but the logical
implementation will not be as
elaborate.
Radio Frequency
A receiver will be placed in the car with The same implementation will take
Reciever/Generator the generator as a key fob. When the
place, but the generator will not be
generator goes out of range (20ft.), the in the form of a key fob.
(Key Fob)
car’s alarm will sound.
Alarm
The alarm will be implemented by
whatever means the car manufacturer
would like. It is strongly suggested that
the car’s built in horn or alarm system be
used given the public’s familiarity to car
alarms and what they entail.
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 4. Feature comparison between full product and prototype
2.2.2 Prototype Functional Description
The prototype will be implemented with the USB-6008 Data Acquisition (DAQ)
device and the LabVIEW software. The DAQ will make it possible to attach several
sensors to a laptop and pass their input values to an application. The LabVIEW software
will take the values from the sensors and allow them be integrated in a visual
programming interface. As a result, logic can be built around the different values the
sensors return.
27
Lab 5 SBIR
Figure 5. DFM Algorithm Flowchart
The logic that the DFM system will use has been illustrated in Figure 5. The
sections that have dotted lines around them have been elaborated on in separate
flowcharts. The DFM system will always run, but will not be active while the car is
turned on. The decision to make the DFM system work only while the car is off is for
safety. If the alarm system were to come on while someone is driving for any reason, the
system could in fact endanger one’s life. Each hour, the DFM system will undergo the
activation process one time as depicted in Figure 6. The system will then check to see if
the car is off before going any further.
When the car is turned off, the first thing the system does is check for the reset
preempt. The alarm will go off if an occupant is present and the key fob is not detected,
28
Lab 5 SBIR
but the temperature is still safe. It will also go off if an occupant is detected and the
temperature is unsafe regardless of the preempt status. If someone wants to leave a
person in the vehicle who is capable of leaving, and the temperature is not dangerous,
they may do so without the alarm system activating if they press the reset switch before
the alarm goes off. When the temperature is safe, the reset switch is used to prevent the
alarm from activating and is referred to as a “preempt.”
After the preempt status is checked the system checks the temperature in the
vehicle. If the temperature is greater than 90 degrees Fahrenheit, or less than 30 degrees
Fahrenheit, the temperature status will be indicated as dangerous. Next, the Life
Detection Algorithm depicted in Figure 7 runs to determine if there is an occupant in the
vehicle. In the event that the temperature is dangerous and someone is in the vehicle, the
alarm system will immediately be activated.
In the event that the temperature is not dangerous but life is detected, the DFM
system will check if the key fob is in range. The range of the key fob is 20ft and should
be attached to the driver’s keys. If the key fob is not detected and an occupant is present,
the DFM system will check the preempt set value. If the preempt is not set, the alarm
system will be activated and will not stop until someone presses the reset switch. The
reset switch will then restart the system and deactivate the alarm.
(This space intentionally left blank.)
29
Lab 5 SBIR
Figure 6. DFM Activation Flowchart
Figure 6 elaborates on the activation process. The activation process is necessary
to continually test each of the sensors in the DFM system so the driver will be aware that
the system is not fully active and requires maintenance. The activation process starts
with each of the sensors sending a small amount of data to be tested. If the data is within
a reasonable range for that particular sensor and the data packet arrived in less than one
second, the sensor is validated. If any of the sensors fail validation the error value is
returned and an error light will be lit for the driver to see. The DFM system will still try
to run if the error is isolated to one of the sensors, but will not run if the error is more
severe.
30
Lab 5 SBIR
Figure 7. DFM Life Detection Algorithm
Figure 7 elaborates on the process the DFM system uses to determine if life is
present in the vehicle. Each sensor has a range of values that when returned indicate that
life has been detected by that particular sensor. After the sensor returns, a value the value
is checked to determine if that sensor detected life. If the sensor indicates that it detected
life, a value based on the priority of the sensor is added to a detection variable. If the
variable’s value is greater than five then the algorithm has determined that life is present.
(This space intentionally left blank.)
31
Lab 5 SBIR
2.2.3 External Interfaces
The external interfaces section describes the different ways one may interact with
the DFM system.
2.2.3.1 Hardware Interfaces
The development team will use each of the sensors to supply data to the
LabVIEW software with the DAQ USB-6008. A switch will be used to disable or
preempt the alarm, and a Bluetooth device will work as a key fob to indicate the driver’s
location. There will be minimal interaction with the sensors since the fully implemented
version is not meant to interface with vehicle occupants.
Figure 8. Environmenal Sensor
The environmental sensor, which is the temperature sensor depicted in Figure 8,
will be manipulated so that the system detects extreme hot and cold readings. The
environmental sensor will sit inside the vehicle in order to read the temperatures a human
might experience. The particular sensor is designed for high precision readings and is
known as a thermistor.
32
Lab 5 SBIR
Figure 9. Life Detection Sensors
The motion sensor, pressure sensor, CO2 sensor, and microphone will all gather data
without human interaction. These sensors are collectively referred to as the Life
Detection Sensors as depicted in Figure 9. The only hardware that should ever directly
be interacted with is the key fob and reset switch.
2.2.3.2 Software Interfaces
The development team interfaces with the DFM system’s software through
LabVIEW. In LabVIEW, a VI (virtual instrument) is created to represent each piece of
hardware in the system. The virtual instrument allows the development team to define
the inputs, outputs, and underlying logic behind each sensor. The virtual instruments are
then integrated into the DFM system in the same manner the hardware will be installed in
the final product. The “Front Panel” is the visual interface with the virtual instrument.
33
Lab 5 SBIR
Figure 10. Alarm VI Front Panel display
For example, in Figure 10 the Alarm VI is shown. The alarm takes the sound file,
and the two switches state “Activate Alarm”, and “Stop Loop”, as input values, and
outputs sound to the computer speakers. The underlying logic for the alarm is displayed
in Figure 11, which is referred to as a “Block Diagram.” The block diagram is also
composed of VIs; this makes it a simple program since all one needs to know is the type
of input values the VI expects, the operation the VI performs, and the type of outputs the
VI will return. The entire DFM system will be programmed with this method, with each
of the sensor’s values streaming in as VI inputs.
(Space intentionally left blank.)
34
Lab 5 SBIR
Figure 11. Alarm VI Block Diagram
2.2.3.3 User Interfaces
The DFM system interfaces with the user exclusively through LabVIEW or the
reset switch. Through LabVIEW, which can be controlled through the keyboard of a PC,
one will be able to activate and deactivate the DFM system. At the point of activation, the
DFM system will conduct a sequence of tests to ensure that all sensors are giving valid
data. Following the activation, the life detection sequence will run until the system is
deactivated through LabVIEW or until the alarm goes off. A user may preempt the alarm
or deactivate the alarm by pressing the reset switch. In the event of an error, a message
will be displayed to the user.
(This space intentionally left blank.)
35
Lab 5 SBIR
2.2.3.4 Communication Protocols and Interfaces
No specific protocol will be used in the DFM system. The driver will have access
to a key fob that will transmit a radio frequency to the DFM system remotely. When the
signal no longer reaches the vehicle, the DFM system will know that the driver is out of
range.
2.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.
2.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.
2.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 5] will begin facilitating life detection.
36
Lab 5 SBIR
The procedures included in the subsections below must occur for the DFM system to be
activated.
2.3.1.2 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.
2.3.1.2.1 Life Detection Sensors
The Life Detection Sensors [Figure 7] 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 7]. 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.
37
Lab 5 SBIR
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.
2.3.1.2.2 Environmental Sensor
The Environmental Sensors [Figure 8] 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.
2.3.1.3 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 4]. The life detection procedures will meet the following functional
requirements.
38
Lab 5 SBIR
1.) The DFM system will check each of the sensors for the values that indicate life
[Figure 5].
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.
2.3.1.4 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.
2.3.1.5 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.
39
Lab 5 SBIR
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.
2.3.1.6 Alarm System
The alarm will be implemented with a sound file played over the speakers of
laptop the DFM system 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.
40
Lab 5 SBIR
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.
2.3.1.7 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.
41
Lab 5 SBIR
2.3.1.8 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.
2.3.1.9 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.
42
Lab 5 SBIR
2.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.
2.3.2.9 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.
2.3.2.10
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.
2.3.2.10.1
Sensor Performance
43
Lab 5 SBIR
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.
2.3.2.10.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.
2.3.2.11
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
44
Lab 5 SBIR
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.
2.3.2.11.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.
2.3.2.11.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.
45
Lab 5 SBIR
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.
2.3.2.12
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.
2.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. Table 5 is a list of assumptions, constraints, and dependencies for
the prototype. Each element in the list was added to facilitate a successful demonstration
of the prototype.
Condition
30° F is the “cool” temperature at
Type
Effect On Requirements
Assumption
46
Cooling device must be present at
Lab 5 SBIR
which point alarm goes off.
90° F is the “hot” temperature at
which point alarm goes off.
demonstration to lower temperature.
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.
Condition
Constraint
Type
Input from CO2 sensor is simulated by the
software.
Effect On Requirements
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 5. Effects of Assumptions, Dependencies, and Constraints on Requirements
2.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. The first two assumptions are that a
47
Lab 5 SBIR
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. 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
them, 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 is in danger 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 cannot 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. 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
48
Lab 5 SBIR
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. 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.
2.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 sensors 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
49
Lab 5 SBIR
travels through oxygen rich blood better than oxygen deficient blood. As the heart beats,
it supplies the body with oxygen rich blood and changes the way infrared light passes
through one’s finger. The variations in the oxygen levels of a person’s blood are directly
correlated with their heart beats. The infrared light can be used to measure a heart beat.
By using the pulse oximeter instead of an accelerometer, the prototype is constrained by
the fact that 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 detects that the car will become dangerous in a matter of minutes, the prototype will
set off the alarm only when danger is eminent.
2.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 its most innovative aspect,
the array of sensors, did not even function. 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
50
Lab 5 SBIR
data acquisition device, it is of the highest level of importance that its software can run
throughout the demonstration.
2.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.
2.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
financially 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.
2.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 that the DFM system is impaired to the
point where it cannot function in a successful manner, the system will be completely
51
Lab 5 SBIR
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.
2.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. It is the responsibility of the system to work without
the driver’s effort and to consistently check that the data it is analyzing is accurate.
3 Test Plan
3.1 Test Plan Objectives
The first functional objective is to test the installation of LabVIEW to determine if
it is suitable for running the DFM prototype. Since LabVIEW is the interface
environment used to interact with the sensors and holds the logic of the DFM system’s
operation, it will be the focus of the presentation. LabVIEW’s drivers and time to load
will be scrutinized in this portion of the demonstration. Success in demonstrating the
DFM system will rely on LabVIEW being fully functional.
The second objective is to demonstrate the various sensors that the DFM system
utilizes. The first sensor to be demonstrated is the one and only environmental sensor, the
temperature sensor. Through the LabVIEW interface, one will be able to see the current
52
Lab 5 SBIR
room temperature and a graph of recently retrieved values. As with all of the other
sensors, a virtual instrument (VI) has been programmed to interpret the sensor’s data into
meaningful information. To begin the Life detection sensors, a pulse oximeter sensor
will be used to aid in determining if life is present in a vehicle. The pulse oximeter will
be attached to an individual’s finger to detect the presence of a pulse. The third device,
the motion sensor, will indicate movement in real time when LabVIEW displays a value
of one for motion detected and zero for none. The hardware alone is capable of
indicating this through a light emitting diode (LED) that turns on when motion is
detected. The fourth device is the pressure sensor; this sensor will be implemented with
simulated data. When the data values reached a threshold indicating a significant
pressure value, LabVIEW will register a positive reading for human detection. The fifth
device is the microphone. The microphone will simply indicate the level of noise
detected through the computer’s microphone. LabVIEW has been programmed to give a
positive life detection value when the noise level reaches volume of a normal
conversation within five feet. Lastly, the CO2 sensor will be demonstrated in LabVIEW
with the use of prerecorded data. The simulated sensor will demonstrate a steadily rising
CO2 value which will indicate life. Each sensor has a pre-defined value that is used in the
life detection algorithm. If the sum of the values returned from sensors is greater than
five, then the algorithm will determined that life is present.
The following objectives address the aspects of the DFM system that require direct
human interaction. The first to be demonstrated is the transmitter/receiver system. A set
of radio frequency devices will interact, one inside the laptop and the other a handheld
device, until one goes out of range. The demonstration of the transmitter/receiver system
53
Lab 5 SBIR
will simulate a parent walking away from the vehicle with a key fob communicating with
the vehicle. The alarm will turn on in response to the prior demonstration as well as one
requiring an extreme temperature value. Lastly, the reset will be used in both previously
mentioned cases to restore the state of the DFM system.
For the last objective the development team will demonstrate the DFM system’s
ability prevent false alarms in order to ensure that the system has a high success rate and
performs its overall goal of saving lives. Risk of false alarms will be assessed based on
the DFM system ability to analyze the different values each sensor provides. If there is
the correct value for life detection the system will accept that a person is present. Adding
more sensors to the implementation would further mitigate that risk. The DFM system
development team increased the number of life detection sensors to five to give the life
detection algorithm a means of accurately assessing the environment. By increasing the
number of sensors further, accuracy could be increased. The development team will be
able to demonstrate this concept by disabling a range of sensor so that the audience can
better understand who the DFM system relies exclusively on the sensors to make
decisions.
Finally, a run-through of the activation process will take place to demonstrate the
DFM system’s ability to assess its own performance. Since this process would run each
time the vehicle is shut off, it is necessary to demonstrate that it can run autonomously.
Successfully passing all objectives will prove that the DFM system can be implemented
inside of a vehicle with minimal human interaction.
54
Lab 5 SBIR
3.2 Test Plan
This section covers the types of tests to be performed, testing schedule, reporting
procedures, resource requirements, the testing environment, and team member
responsibilities. The test plan describes the tests that will take place when demonstrating
the DFM system. The functions of the DFM system that are tested are described in the
team member responsibilities.
3.2.1 Testing Approach
The DFM system prototype is tested through unit, integration, system testing
procedures. By partitioning the prototype in separate elements, the review panel can
better follow the evaluation of the DFM system’s performance. Steps one through six are
the unit tests, step seven is the integration test, step eight is the system test, and step nine
is risk mitigation. A basic layout of the DFM system is provided in the major functional
components diagram in Figure 1.
(This space intentionally left blank.)
55
Lab 5 SBIR
Figure 12. Phase 1 prototype major functional component diagram
The first step of testing the individual components of the DFM system is to test
the LabVIEW setup. LabVIEW will be tested to ensure that it is installed and can be run
with no delays. LabVIEW is absolutely necessary for the DFM system since all of the
logic and interface was implemented using LabVIEW.
The second step is making sure that the environmental sensor performs accurately
and can make adjustments in a relatively short period of time. The thermistor will
generate values to be displayed in LabVIEW, which will coincide with the temperature of
the room or the temperature extremes it will be exposed to. A temperature sensor will
56
Lab 5 SBIR
determine when it is unsafe for anyone to be in the vehicle and therefore must take
measurements at all times.
The third step is to test the life detection sensors to make sure that each sensor can
perform its task with a high level of precision and accuracy. The first of the life detection
sensors is the pulse oximeter. The pulse oximeter will generate values to indicate that it
is working, and then it will be evaluated based on its ability to generate values within an
acceptable range. The pulse oximeter will be expected to generate values within an
acceptable time period as well. The motion sensor will also generate values to indicate
that it is working, and then it will be evaluated based on its ability to generate values
within an acceptable range. The motion sensor will be expected to generate values within
an acceptable time period as well. The pressure sensor will be simulated. The sensor will
still need to send the signal in the required time. The microphone after receiving sound
data will indicate when a specified decibel level is reached and will do so within a
specified period of time. The CO2 sensor will be simulated. The sensor will still need to
send the signal in the required time.
The fourth, fifth, and sixth steps will test the human interaction devices to ensure
they are working properly. The transmitter/receiver system will be used to indicate that
the driver has left the vehicle. The transmitter and receiver must be test in tandem since
they confirm one another’s data. The transmitter will send a signal to the receiver and the
receiver will indicate that it is receiving data from that particular device. The transmitter
and receiver will also need to send and respond it the required time. The next device is
the alarm; the alarm will receive an activation signal and a signal to stop. This will cause
the alarm sound file to play for a short instance. The alarm also needs to go off in the
57
Lab 5 SBIR
specified time. Lastly, the reset is tested. The system needs to reset the DFM system to
its initial state when pressed. It also needs to reset the DFM system is the required time.
The seventh step will test the DFM system activation process. The activation
process will be tested for checking each sensor and that is finishes the activation in the
specified time. The activation process is necessary to ensure that the system can run
autonomously. The activation process tests each of the sensors values to make sure they
are acceptable.
The ninth step is system testing, which will involve running the DFM system
trough a set of scenarios to ensure that all of the logic is correctly implemented. This test
involves setting off enough sensors for the DFM system to detect life while the
preemptive reset is enabled and the temperature sensor is forced off. The DFM system
should continue to run until the preemptive reset is disabled of the temperature value
reaches 89. Pressing the reset button will reset the system and disable the preemptive
reset. The second feature that the system test must cover is testing when the driver is
gone and the temperature is low, which will cause an alarm. The last feature is the error
system that was programmed into the DFM. In the event that too few sensors are
working, the driver will be alerted. Likewise, if both the key fob and temperature devices
are not work the driver must also be alerted.
All of the tests will be performed using LabVIEW, the DFM system software, and
the previously mentioned sensors. Each of the sensors will be verified using the graph
data that the DFM interface provides and the LEDs programmed to indicate exceptional
values. Logs of all the data generated during the prototype demonstration can be
observed for further validation.
58
Lab 5 SBIR
3.2.2 Identification of Tests
The system will be tested based on a break-down or its constituent parts. To
ensure that the system is thoroughly tested, the DFM system will test the software
interface, the two groups of sensors, the 3 aspects of human interactivity, and the
automated self test. The items required to identify the tests are category id, category
description, test case number, and the description the test case. Table 6 shows the test
cases that will be performed; specific details for each test are described in section 4.1.
Category ID
1
2
3
4
Description
Test Case
LabVIEW
1.1
Environmental Sensor
Life Detection Sensors
Alarm
6
Reset
7
Verify temperature sensor’s behavior
and performance.
3.1
Verify pulse oximeter sensor’s behavior
and performance.
3.2
Verify pressure sensor’s behavior and
performance.
3.3
Verify microphone’s behavior and
performance.
3.4
Verify C02 sensor’s behavior and
performance.
3.5
Verify motion sensor’s behavior and
performance.
4.1
Verify transmitter’s behavior and
performance
4.2
Verify receiver’s behavior and
performance.
5.1
Verify alarm’s behavior and
performance.
6.1
Verify behavior of the DFM system while
reset is activated.
7.1
Verify each sensor will send a signal to
LabVIEW.
7.2
Verify each sensor’s value will be greater
or equal to its rated minimum value.
Activation
59
Verity LabVIEW is installed and
operational.
2.1
Transmitter and Receiver
5
Description
Lab 5 SBIR
7.3
Verify each sensor’s value will be less
than or equal to its rated maximum
value.
7.4
Verify each sensor will return a value
within 10 seconds.
7.5
Verify the entire activation will take no
more than 60 seconds.
8
Risks Mitigation
8.1
Verify error detection
9
System Integration
9.1
Verify behavior and performance for all
components of the DFM system when
components are integrated.
Table 6. DFM system prototype test cases by category
3.2.3 Test Schedule
The demonstration of the DFM system prototype is scheduled to take 60 minutes.
The first five minutes of the presentation will be devoted to the setup of the DFM system.
The following 10 minutes will be used to explain the concept of the DFM system and
give an introduction of the development team. The remaining time has been scheduled
out in Table 7.
Start Time
Duration
Test Objective
Test
Event(s)
Dependencies
Comments
(hours:min) (minutes)
0:15
1
LabVIEW
1.1
N/A
N/A
0:16
5
Environmental Sensor
2.1
N/A
N/A
0:21
10
Life Detection Sensors
3.1, 3.2,
3.3, 3.4,
3.5
N/A
N/A
0:31
1
Transmitter and Receiver
4.1, 4.2
N/A
N/A
0:32
1
Alarm
5.1
N/A
N/A
0:33
1
Reset
6.1
N/A
N/A
0:34
5
Activation
7.1, 7.2,
7.3, 7.4
N/A
N/A
0:39
1
Risks Mitigation
8.1
N/A
N/A
0:40
5
System Integration
9.1
N/A
N/A
60
Lab 5 SBIR
Table 7. DFM system prototype test schedule
3.2.4 Fault Reporting and Data Recording
A member from the development team is responsible for recording the results of
each of the tests and taking notes on the DFM system’s performance. The tests will be
recorded as either passing or failing. Each test case will be verified using the graph data
generated in LabVIEW and the static data each sensor displays in the DFM interface. As
each of the virtual instruments run in LabVIEW a log file will be generated with the
values that were displayed on the DFM interface. Performance can be assessed by
observing the log files generated throughout the demonstration.
3.2.5 Resource Requirements
The demonstration of the DFM system prototype will require a copy of the
LabVIEW software to be installed at least two laptops with one available USB port. One
laptop will be used for the presentation and the other one for a backup. A DAQ USB6008 must be used to interact with the sensors, and two nine volt batteries must be used
to power the sensors. Both laptops will need the drivers for interfacing with the DAQ to
be installed. Also all of the virtual instruments and accompanying media files must be
present on both laptops. Each of the sensors that interface with LabVIEW through the
DAQ must be connect appropriately. A thermistor will be used for measuring the room
temperature. A hair dryer will be used for heating the thermistor to a temperature above
90 degrees Fahrenheit, and a cup filled with ice will be used to demonstrate that the
thermistor can be cooled. A radio controlled car controller will be used to interface with
the DFM systems radio frequency system. The motion sensor, which was assembled
with a circuit kit and ultrasonic motion sensors, will be used to detect movement. A
pulse oximeter will be used to measure the heart rate of one of the team members. A
61
Lab 5 SBIR
computer microphone will be used to measure the amount of noise in the room, and the
computer’s speakers will be used to play the alarm sound file. The laptop will also need
a program capable of viewing ASCII text files generating by the logging feature of the
DFM system.
3.2.6 Test Environment
The prototype demonstration will take place in the conference room on the third
floor of Computer Science and Engineering building. A depiction of the room is
provided in Figure 13. The DFM system development team will be seated at the back of
the room in front of “Projector Screen 2”, with the review panel facing the development
team on the opposite side of the room.
Figure 13. Presentation room layout
62
Lab 5 SBIR
The team member responsible for taking notes and performing documentation
will sit on the same side of the room as the review panel. The team member responsible
for running the LabVIEW software will sit at the table behind the depiction of “Laptop 2”
from figure 13. The LabVIEW interface will be displayed on both projector screens.
Prior to the demonstration the hardware will be connected to either the computer directly
or through the data acquisition unit (DAQ). The sensors will be placed across the table
for the review panel to observe prior to their use in the presentation.
3.2.7 Test Responsibilities
The project manager is responsible for beginning the presentation and introducing
the development team. A second team member will assist the project manager in
delivering the presentation of the DFM system by performing the tests in LabVIEW. A
third team member will be responsible for influencing each of the sensors in order to
make them generate data within a desired range. The third member of the team will heat
and cool the temperature sensor and will be responsible for making the motion sensor
detection movement. A fourth team member will be responsible for influencing the
microphone and the pulse oximeter. The fourth team member will have to place the pulse
oximeter on their finger and may have to direct the microphone so that it may receive an
optimal reading. The fifth team member will be responsible for documenting which of
the test cases passed and notes pertaining to the performance of the system throughout the
presentation.
3.3 Test Procedures
The test procedures describe the each of the tasks that will take place in order to
effectively test the DFM system. Likewise, this section will address each test’s
63
Lab 5 SBIR
relationship with the previously defined requirements, and what the expected outcome
will be for each of the test cases. The procedures will effectively map out the
demonstration of the DFM system prototype.
3.3.1 Test Case Names and Identifiers
Requirements Traceability – a reference to the requirements that the
test case will address.
Description of Test - a short description of the test’s goals.
Test Inputs – details of the input parameters used when performing
the test.
Test Procedure – instructions of how to perform the test.
Expected Result – the results that are desired for the test used to verify
that the test had a positive result.
Special Instructions – details about performing the test the team
member needs to be aware of in order to successfully perform the
operation.
Test Case
1.1
Requirements
Traceability
3.1.7.1, 3.1.7.2, 3.1.7.3, 3.1.7.4, 3.1.7.5, 3.1.7.6, 3.1.7.7, 3.1.8.1,
3.1.8.2, 3.1.8.3
Description of Test
Verify LabVIEW is installed and operational
Test Inputs
N/A
1. Double click the LabVIEW the DFM.vi file to launch the
program.
2. Check version to match version 8.2 or greater.
3. Locate DFM VI, go to the block diagram and double click
the DAQ assistant block to verify the DAQ is working.
4. Verify sensors are connected to the correct channels on
DAQ.
Test Procedure
64
Lab 5 SBIR
5. Verify Data points are correct.
6. Verify the wires within the prototype box are connected
correctly.
Expected Results
LabVIEW installed and fully operational
Special Instructions
1. Exit all non-essential programs before launching LabVIEW.
Test Case
2.1
Requirements
Traceability
3.1.1.1.1, 3.1.1.1.2, 3.1.1.3.1, 3.1.1.3.2, 3.1.3.1, 3.1.3.2, 3.1.8.1,
3.1,8.2, 3.1.8.3, 3.2.2.2.1, 3.2.2.2.2, 3.2.2.2.3, 3.2.2.2.4, 3.2.2.2.5,
3.2.3.1.1, 3.2.3.1.2, 3.2.3.1.3, 3.2.3.1.4, 3.2.3.2.1, 3.2.3.2.2, 3.2.3.2.3
Description of Test
Verify temperature sensor’s behavior and performance
1. Input value greater than 30 ºF and less than 90 ºF
2. Input value less than or equal to 30 ºF
3. Input value greater than or equal to 90 ºF
1. Turn Temperature sensor switch on.
2. Turn all other sensors off.
3. Turn DFM VI on.
4. Verify temperature value.
5. Apply cool air to the temperature sensor.
6. Verify temperature value.
7. Apply hot air to the temperature sensor.
8. Verify temperature value.
1. System will not react when temperature is between 30º F and
90º F.
2. Alarm will sound when temperature is below or equal to 30
ºF.
3. Alarm will sound when temperature is above or equal to 90 º
F.
1. For cooling the temperature sensor, place sensor in ice.
2. For heating the sensor, place sensor in close proximity to
hair dryer or heater.
Test Inputs
Test Procedures
Expected Results
Special Instructions
Test Case
3.1
Requirements
Traceability
3.1.1.1.1, 3.1.1.1.2, 3.1.1.2.1, 3.1.1.2.2, 3.1.2.1, 3.1.2.2, 3.1.2.3,
3.1.2.4, 3.1.3.1, 3.1.3.2, 3.1.8.1, 3.1.8.2, 3.1.8.3, 3.2.2.1.3, 3.2.2.2.1,
3.2.2.2.2, 3.2.2.2.3, 3.2.2.2.4, 3.2.2.2.5
Description of Test
Verify pulse oximeter sensor’s behavior and performance
Test Inputs
Pulse sensor’s signal
1. Turn pulse oximeter sensor switch on.
2. Turn all other sensors off.
3. Turn DFM VI on.
Test Procedures
65
Lab 5 SBIR
4.
5.
6.
7.
8.
1.
Verify value from sensor.
Verify danger value.
Attach pulse oximeter’s clip to finger of test subject.
Verify value from sensor.
Verify danger value.
No occupant was detected while pulse oximeter’s clip was
not attached to test subject’s finger and danger value of zero
is returned.
2. Occupant was detected when pulse oximeter was attached to
finger of subject and danger value of four is returned.
Expected Results
Special Instructions
N/A
Test Case
3.2
Requirements
Traceability
3.1.1.1.1, 3.1.1.1.2, 3.1.1.2.1, 3.1.1.2.3, 3.1.2.1, 3.1.2.2, 3.1.2.3,
3.1.2.4, 3.1.3.1, 3.1.3.2, 3.1.8.1, 3.1.8.2, 3.1.8.3, 3.2.2.1.2, 3.2.2.2.1,
3.2.2.2.2, 3.2.2.2.3, 3.2.2.2.4, 3.2.2.2.5
Description of Test
Verify pressure sensor’s behavior and performance.
1. Simulated signal
1. Turn on pressure sensor’s switch.
2. Turn off all other sensors.
3. Verify value from sensor.
4. Verify danger value.
5. Apply simulated pressure signal.
6. Verify value from sensor.
7. Verify danger value
1. LED turned off with no simulated signal and danger value of
zero is returned.
2. LED turned on with simulated signal and danger value of
two is returned.
Test Inputs
Test Procedures
Expected Results
Special Instructions
N/A
Test Case
3.3
Requirements
Traceability
3.1.1.1.1, 3.1.1.1.2, 3.1.1.2.1, 3.1.1.2.4, 3.1.2.1, 3.1.2.2, 3.1.2.3,
3.1.2.4, 3.1.3.1, 3.1.3.2, 3.1.8.1, 3.1.8.3, 3.2.2.1.1, 3.2.2.2.1,
3.2.2.2.2, 3.2.2.2.3, 3.2.2.2.4, 3.2.2.2.5
Description of Test
Verify microphone’s behavior and performance.
Test Inputs
1. Tester’s voice
1. Turn on microphone’s switch.
2. Turn off all other sensors.
3. Verify value from microphone.
4. Verify danger value.
Test Procedures
66
Lab 5 SBIR
5.
6.
7.
1.
Tester speaks into microphone.
Verify value from microphone.
Verify danger value.
LED turned off when no existence of noise and danger value
of zero is returned.
2. LED turned on when tester speaks into microphone and
danger value of one is returned.
Expected Results
Special Instructions
1. Ensure silence during testing, except for the voice of the tester.
Test Case
3.4
Requirements
Traceability
3.1.1.1.1, 3.1.1.1.2, 3.1.1.2.1, 3.1.1.2.5, 3.1.2.1, 3.1.2.2, 3.1.2.3,
3.1.2.4, 3.1.3.1, 3.1.3.2, 3.1.8.1, 3.1.8.2, 3.1.8.3, 3.2.2.1.4, 3.2.2.2.1,
3.2.2.2.2, 3.2.2.2.3, 3.2.2.2.4, 3.2.2.2.5
Description of Test
Verify C02 sensor’s behavior and performance.
Test Inputs
1. Simulated signal.
1. Turn on C02 sensor’s switch.
2. Turn off all other sensors.
3. Verify value from sensor.
4. Verify danger value.
5. Apply simulated C02 signal.
6. Verify value from sensor.
7. Verify danger value.
1. LED turned off with no simulated signal and danger value of
zero is returned.
2. LED turned on with simulated signal and danger value of
three is returned.
Test Procedures
Expected Results
Special Instructions
N/A
Test Case
3.5
Requirements
Traceability
3.1.1.1.1, 3.1.1.1.2, 3.1.1.2.1, 3.1.1.2.6, 3.1.2.1, 3.1.2.2, 3.1.2.3,
3.1.2.4, 3.1.3.1, 3.1.3.2, 3.1.8.1, 3.1.8.2, 3.1.8.3, 3.2.2.2.1, 3.2.2.2.2,
3.2.2.2.3, 3.2.2.2.4, 3.2.2.2.5
Description of Test
Verify motion sensor’s behavior and performance.
Test Inputs
1. Displacement of object.
1. Turn on motion sensor’s switch.
2. Turn off all other sensors.
3. Verify value from sensor.
4. Verify danger value.
5. Move object greater than one inch.
6. Verify value from sensor.
7. Verify danger value.
Test Procedures
67
Lab 5 SBIR
1. LED turned off without movement and danger value of zero
is returned.
2. LED turned on with movement and danger value of three is
returned.
Expected Results
Special Instructions
1. Ensure there is no movement in range of the motion sensor,
except for the movement of the test subject.
Test Case
4.1
Requirements
Traceability
3.1.4.1, 3.1.4.2, 3.1.4.3, 3.2.2.2.1, 3.2.2.2.2, 3.2.2.2.3, 3.2.2.2.4,
3.2.2.2.5, 3.2.4.1, 3.2.4.2, 3.2.4.3
Description of Test
Verify transmitter’s behavior and performance.
Test Inputs
N/A
1. Turn on transmitter’s switch.
2. Turn off all other sensors.
3. Verify results.
1. LED turned off when transmitter’s switch turned off.
2. LED turned on when transmitter’s switch turned on.
Test Procedures
Expected Results
Special Instructions
1. Ensure no other BluTooth devices are enabled or in range during
testing.
Test Case
4.2
Requirements
Traceability
3.1.4.1, 3.1.4.2, 3.1.4.3, 3.2.2.2.1, 3.2.2.2.2, 3.2.2.2.3, 3.2.2.2.4,
3.2.2.2.5, 3.2.4.1, 3.2.4.2, 3.2.4.3
Description of Test
Verify receiver’s behavior and performance.
Test Inputs
1. Signal from transmitter.
1. Turn on receiver and transmitter’s switch.
2. Turn off all other sensors.
3. Verify results.
4. Locate transmitter beyond 20 ft.
5. Verify results.
1. LED turned on when transmitter is within 20 ft.
2. LED turned off when transmitter is beyond 20 ft.
Test Procedures
Expected Results
Special Instructions
1. Ensure no other BluTooth devices are enabled or in range during
testing.
Test Case
5.1
Requirements
Traceability
3.1.5.1, 3.1.5.2, 3.1.5.3, 3.1.5.4, 3.1.5.5, 3.1.5.6, 3.1.5.7, 3.1.5.8,
3.1.5.9
68
Lab 5 SBIR
Description of Test
Verify alarm’s behavior and performance.
Test Inputs
1. Signal from LabVIEW.
1. Send signal to alarm.
2. Verify alarm goes off.
Test Procedures
Expected Results
1. Alarm will sound when signal is received.
Special Instructions
1. Ensure speaker volume is enabled.
Test Case
6.1
Requirements
Traceability
3.1.6.1, 3.1.6.2, 3.1.6.3, 3.1.6.4, 3.1.6.5, 3.1.6.6
Description of Test
Verify behavior of the DFM system while reset is activated.
Test Inputs
N/A
1.
2.
3.
4.
Test Procedures
5.
6.
1.
Expected Results
2.
3.
Set temperature high and occupancy level to 5.
Press reset button.
Verify state of DFM system.
Set temperature back to normal state and occupancy level to
5.
Press reset button.
Verify state of DFM system.
If reset is pressed while occupancy has been detected and
temperature is high, the system is not reset.
If reset is pressed and temperature is not high but an
occupant is detected and transmitter is out of range, the
system and alarm are reset.
If the reset is pressed with no current alarm sounding, the
system is reset.
Special Instructions
N/A
Test Case
7.1
Requirements
Traceability
3.2.1.1, 3.2.1.2, 3.2.1.3, 3.2.1.4, 3.2.1.5
Description of Test
Verify each sensor will send a signal to LabVIEW.
1. What each sensor is sensing.
2. Simulated signal if sensor is simulated
1. Turn on the switch for one of the sensors.
2. Verify result.
3. Turn off the sensor.
4. Repeat steps 1-3 for each of the remaining sensors.
Test Inputs
Test Procedures
Expected Results
1. For each sensor, a signal is received.
69
Lab 5 SBIR
Special Instructions
N/A
Test Case
7.2
Requirements
Traceability
3.2.1.1, 3.2.1.2, 3.2.1.3, 3.2.1.4, 3.2.1.5
Description of Test
Verify each sensor’s value will be greater than or equal to its rated
minimum value.
1. What each sensor is sensing.
2. Simulated signal if sensor is simulated.
Test Inputs
1.
2.
3.
4.
Test Procedures
Turn on the switch for one of the sensors.
Verify result.
Turn off the sensor.
Repeat steps 1-3 for each of the remaining sensors.
Expected Results
1. For each sensor, the signal that is received is greater than or equal
to its rated minimum value.
Special Instructions
N/A
Test Case
7.3
Requirements
Traceability
3.2.1.1, 3.2.1.2, 3.2.1.3, 3.2.1.4, 3.2.1.5
Description of Test
Verify each sensor’s value will be less than or equal to its rated
maximum value.
1. What each sensor is sensing.
2. Simulated signal if sensor is simulated.
Test Inputs
1.
2.
3.
4.
Test Procedures
Turn on the switch for one of the sensors.
Verify result.
Turn off the sensor.
Repeat steps 1-3 for each of the remaining sensors.
Expected Results
1. For each sensor, the signal which is received is less than or equal
to its rated maximum value.
Special Instructions
N/A
Test Case
7.4
Requirements
Traceability
3.2.1.1, 3.2.1.2, 3.2.1.3, 3.2.1.4, 3.2.1.5
70
Lab 5 SBIR
Description of Test
Test Inputs
Test Procedures
Verify each sensor will return a value within 10 seconds.
1. What each sensor is sensing.
2. Simulated signal if sensor is simulated.
1. Turn on the switch for one of the sensors.
2. Verify result.
3. Turn off the sensor.
4. Repeat steps 1-3 for each of the remaining sensors.
Expected Results
1. For each sensor, the signal was received in less than 10 seconds.
Special Instructions
N/A
Test Case
7.5
Requirements
Traceability
3.2.1.1, 3.2.1.2, 3.2.1.3, 3.2.1.4, 3.2.1.5
Description of Test
Verify the entire activation will take no more than 60 seconds.
1. What each sensor is sensing.
2. Simulated signal if sensor is simulated.
1. Start the system.
2. Verify results.
Test Inputs
Test Procedures
Expected Results
1. System was activated in less than or equal to 60 seconds.
Special Instructions
N/A
Test Case
8.1
Requirements
Traceability
3.1.2.1, 3.1.2.2, 3.1.2.3, 3.1.2.4
Description of Test
Verify error detection.
N/A
1. Disable various sensors in order to change total value for
priority codes.
1. 1. When total priority values for disabled sensors is greater
that 7 then error message will be generated.
Test Inputs
Test Procedures
Expected Results
Special Instructions
N/A
Test Case
9.1
Requirements
Traceability
3.1.2.1, 3.1.2.2, 3.1.2.3, 3.1.2.4, 3.1.3.1, 3.1.3.2, 3.1.4.1, 3.1.4.2,
3.1.4.3, 3.1.5.1, 3.1.5.2, 3.1.5.3, 3.1.5.4, 3.1.5.5, 3.1.5.6, 3.1.5.7,
3.1.5.8, 3.1.5.9, 3.1.8.1, 3.1.8.2, 3.1.8.3
Description of Test
Verify behavior and performance for all components of the DFM
71
Lab 5 SBIR
system when components are integrated.
1. All sensor signals.
2. Transmitter signal.
Test Inputs
Test Procedures
Expected Results
Special Instructions
1. Create movement alone.
2. Verify no alarm.
3. Create movement and a heartbeat signal to demonstrate
occupancy detection.
4. Verify alarm.
1. 1. No alarm with motion only and alarm sounded with
motion and heartbeat.
N/A
Traceability to Requirements
Component
Requirement ID
Sensor
overview
3.1.1.1.1
x
x
x
x
x
x
3.1.1.1.2
x
x
x
x
x
x
3.1.1.2.1
x
x
x
x
x
3.1.1.2.2
x
Life detection
sensors
1.1 2.1 3.1 3.2 3.3 3.4 3.5 4.1 4.2 5.1 6.1 7.1 7.2 7.3 7.4 7.5 8.1 9.1
3.1.1.2.3
x
3.1.1.2.4
x
3.1.1.2.5
x
3.1.1.2.6
Environmental
sensor
Life detection
procedures
Environmental
evaluation
procedures
Transmitter
and receiver
functions
Alarm system
x
3.1.1.3.1
x
3.1.1.3.2
x
3.1.2.1
x
x
x
x
x
x
x
3.1.2.2
x
x
x
x
x
x
x
3.1.2.3
x
x
x
x
x
x
x
3.1.2.4
x
x
x
x
x
x
x
3.1.3.1
x
x
x
x
x
x
x
3.1.3.2
x
x
x
x
x
x
x
3.1.4.1
X
x
x
3.1.4.2
X
x
x
3.1.4.3
X
x
x
3.1.5.1
x
x
3.1.5.2
x
x
3.1.5.3
x
x
72
Lab 5 SBIR
Reset
procedures
labView setup
Simpulation
procedures
3.1.5.4
x
x
3.1.5.5
x
x
3.1.5.6
x
x
3.1.5.7
x
x
3.1.5.8
x
x
3.1.5.9
x
x
3.1.6.1
x
3.1.6.2
x
3.1.6.3
x
3.1.6.4
x
3.1.6.5
x
3.1.6.6
x
3.1.7.1
x
3.1.7.2
x
3.1.7.3
x
3.1.7.4
x
3.1.7.5
x
3.1.7.6
x
3.1.7.7
x
3.1.8.1
x
x
x
x
x
x
x
x
3.1.8.2
x
x
x
x
x
x
x
x
3.1.8.3
x
x
x
x
x
x
x
x
Requirement ID
1.
1
2.
1
3.
1
3.
2
3.
3
3.
4
3.
5
Component
DFM system
activation
Sensor
performance
7.
1
7.
2
7.
3
7.
4
3.2.1.1
x
x
x
x
3.2.1.2
x
x
x
x
x
3.2.1.3
x
x
x
x
x
3.2.1.4
x
x
x
x
x
3.2.1.5
x
x
x
x
x
3.2.2.1.1
x
3.2.2.1.2
Procedure
performance
3.2.2.1.3
x
x
3.2.2.1.4
x
73
4.
1
4.
2
5.
1
6.
1
7.
5
x
8.
1
9.
1
Lab 5 SBIR
Sensor
Performance
Procedure
performance
Transmitter
and receiver
functions
3.2.2.2.1
x
x
x
x
x
x
X
x
3.2.2.2.2
x
x
x
x
x
x
X
x
3.2.2.2.3
x
x
x
x
x
x
X
x
3.2.2.2.4
x
x
x
x
x
x
X
x
3.2.2.2.5
x
x
x
x
x
x
X
x
3.2.3.1.1
x
3.2.3.1.2
x
3.2.3.1.3
x
3.2.3.1.4
x
3.2.3.2.1
x
3.2.3.2.2
x
3.2.3.2.3
x
3.2.4.1
X
x
3.2.4.2
X
x
3.2.4.3
X
x
Table 8, Traceability to requirements table
4 User Manual
4.1 Introduction (David)
Welcome to the Don’t Forget Me system (DFM System) prototype. We thank
you for your support in the prototype possess. This document includes an overview of
the DFM system and the functional systems therein. It also includes information on how
to use the prototype, what testing should be done, and troubleshooting information. Again
we thank you for your interest in the DFM system prototype.
74
Lab 5 SBIR
4.2 Product Overview (David)
The DFM system is a life saving tool utilizing sensor technology designed to
prevent an occupant from being left behind in a vehicle. The system will be implemented
into vehicles at the time of their manufacture. It will most likely be powered off the
internal car battery, but this will be left up to the manufacturer. In a vehicle installed
with a DFM system, it will be active at any time the car is parked, including when the car
itself is off. Utilizing hardware sensors such as a pressure sensor, a motion sensor, and a
heartbeat sensor, the software algorithm will calculate the probability of an occupant
being in the seat. It will also calculate how far the driver is from the vehicle by
measuring the signal strength of a transmitter on the vehicle key (Ballentine, David
2008).
When the DFM system concludes that there is an occupant in the seat, and if the
driver is more than twenty feet away from the vehicle, the vehicle’s alarm will sound.
There is the option to temporarily disable the alarm. A switch on the occupant’s seat will
turn off the alarm. The driver or a child old enough can activate this switch. The
deactivation of the switch will cause the system to enter standby mode. It will continue
to monitor the occupant, as well as the conditions inside the car. If the conditions
become too hostile, the alarm will sound again. This time it will not be possible to turn
the alarm off without the occupant being removed from the vehicle (Ballentine, David
2008).
4.3 Getting Started (David)
This section discusses the steps to get started in running the DFM system
prototype. The main steps are broken down into two categories. The first category is the
75
Lab 5 SBIR
hardware aspect and what must be done with the hardware to get the prototype set up.
The second category is the software aspect.
4.3.1 Hardware
Before the prototype can be run, certain hardware dependencies must be correctly
assembled. The main hardware is the sensors used within the prototype as depicted in
Figure 14 and Figure 15. Figure 14 shows the project box and the three wires that
connect from the back. Visible in Figure 14 from left to right is the USB connector for
the DAQ, the pulse oximeter, the two circles on the box are for motion sensing, and the
rightmost device is the temperature sensor.
Figure 14. DFM system project box
Figure 15 shows the inside of the DFM system project box. To the top left of the
box you can see the DAQ with National Instrument’s insignia. To the right of the DAQ
is the mini-breadboard which has wiring to support the pulse oximeter configuration, and
the radio frequency receiver transmission. The small board below is the radio frequency
receiver. Lastly, the larger circuit board at the bottom of the box is the circuitry for the
76
Lab 5 SBIR
motion sensor. All power for the prototype is supplied by the two nine volts in the
project box.
Figure 15. DFM system project box interior
As the sensors can also be simulated, the connection of the actual hardware
sensors is optional, but required if you want to check the hardware functionality of that
particular sensor. The DAQ must also be connected to the compliant computer correctly.
The following steps must be taken.
Step 1: Ensure the computer used is in proper working order.
Step 2: Connect the motion sensor to the DAQ.
Step 3: Connect the temperature sensor to the DAQ.
Step 4: Connect the pulse sensor to the DAQ.
Step 5: Connect the RF receiver to the DAQ.
77
Lab 5 SBIR
Step 8: Connect the microphone to the computer
Step 9: Connect the DAQ to the computer via USB.
4.3.2 Software
After the hardware is correctly installed, the software must be initiated. The DFM
Prototype runs inside LabVIEW. The following steps must be taken.
Step 1: Correctly install LabVIEW onto the computer.
Step 2: Update the computer with the DAQ drivers.
Step 3: Ensure the prototype file DFM.vi is on the computer.
Step 4: Run LabVIEW and open the prototype VI file.
Step 5: Ensure all the sensor VI’s are correctly loaded.
Step 6: Ensure the CarHorn.wav file is available in the prototype directory.
Step 7: Ensure the CarHorn.wav file is correctly linked in the prototype.
Step 8: Ensure there are log files for every sensor created.
Step 9: Ensure the sensor log files are correctly referenced in the prototype.
4.4 Prototype Procedures (Hernan)
This section demonstrates the procedure of how to operate the DFM system
prototype GUI. The procedure is divided into four different parts: initialization
procedure, activation procedure, the running state, and termination procedure of the DFM
system VI. The following are procedures of how to operate the GUI.
78
Lab 5 SBIR
4.4.1 Initialization Procedure
1.
To select a simulated sensor, select the radio button that says, “Simulated”. The
VI will generate random numbers meant to match the actual hardware. Figure 3
shows a panel where simulated signal has been selected.
Figure 16. The DFM system VI simulated signal
2. To select a real sensor, select the radio button that says, “Real”. The VI will use
the data is generated from the actual hardware device. Figure 4 shows a panel
where the real signal has been selected.
79
Lab 5 SBIR
Figure 17. The DFM system VI real sensor signal
3. To force a sensor to indicate that life is detected, select the radio button that says,
“Force On”. It will set the sensor data value to 100, which is high enough to make
all the sensors life detection value positive. Figure 5 shows a panel where force on
has been selected.
Figure 18. The DFM system VI force on signal
80
Lab 5 SBIR
4. To turn off a sensor, select the radio button that says, “Force Off”. It will set the
sensor data value to zero. Figure 6 shows no signal has been chosen.
Figure 19. The DFM system VI force off signal
5. To disable a sensor, select the radio button that says, “Disable”. The VI will not
produce any signals to the sensor. Figure 7 shows no signal has been chosen.
Figure 20. The DFM system VI disable signal
81
Lab 5 SBIR
4.4.2 Activation Procedure
1. Click the “Run” button on the toolbar.
Figure 21. LabView run button
2. The program will continue running until the danger level reaches a value greater
than five. The alarm will then activate and the alarm light will turn on. Figure 21
shows an example where the danger level is greater than five.
Figure 22. DFM system Danger Level indicator
82
Lab 5 SBIR
3. To restart the system, select the “Reset” button. Make sure that the reset light is
off, which means reset has been done or there is no need to reset the system,
before running the VI again. Figure 10 shows that reset light is off, which indicate
that the VI is ready to run again.
Figure 23. The DFM system VI reset button (light off).
4.4.3 The Running State
1. To view each sensor’s data in the form of a graph, click the tab on the graph
display. Figure 11 shows an example of the simulated microphone data graph.
83
Lab 5 SBIR
Figure 24. The DFM system VI microphone graph example
2. All sensors and the key fob can be switched to the simulated, real, off, or force on
state from their current state while the VI is running.
3. A life detection sensor light indicator is turned on when a sensor has detected life;
otherwise, the light is off. Figure 25 shows an example where microphone and
C02 sensors have detected life; however, the pulse, motion, and pressure sensors
have not detected life.
Figure 25. The DFM system VI life detection sensors light indicators
4. The temperature sensor light indicator turns on when temperature is above 89 °F;
however, the key fob light indicator is turned on when the key fob reading is
above one. If the temperature sensor and the key fob are both simulated or real,
then either one of them that goes beyond the predefined limit first will activate the
alarm, of course unless the danger level is 5 or below. Figure 13 shows an
example of both sensors that are simulated and neither is activated. The system
will only activate the alarm if the danger level is above five and either is on.
84
Lab 5 SBIR
Figure 26. The DFM system VI temperature sensor and key fob
5. To ignore the key fob reading, turn on “Preempt” switch.
Figure 27. The DFM system VI preempt switch
6. To pause the VI, click the “Pause” button on the toolbar.
85
Lab 5 SBIR
Figure 28. LabView pause button
4.4.4 Termination Procedure
To terminate the running VI, click the “Stop” button on the toolbar.
Figure 29. LabView stop button
1. Normally after termination, the reset light remains on. The reset light turns on to
remind the user that the system must be reset before running again, so make sure
to reset the system every time the reset light remains on. Just click the reset
86
Lab 5 SBIR
button to reset the alarm setting. Once the reset button is selected, the light will
turn off. Figure 30 shows that the system needs to be reset before running again.
Figure 30. The DFM system VI reset button (light on).
4.5 Product Features (Daniel)
You will find descriptions of the major components of the Don’t Forget Me
(DFM) system prototype in this section. The individual components make up the major
functional component diagram for the DFM system. The listed components include:
DFM interface, motion sensor, pulse oximeter, CO2 sensor, temperature sensor,
microphone, pressure sensor, and blue tooth transmitter and receiver. The Major
Functional Component Diagram (MFCD) for the DFM system can be seen in Figure 31.
The environment sensor utilized in the DFM system can be seen in Figure 32. A
thermistor senses the temperature within the compartment of the vehicle. The life
detection sensors consist of CO2 sensor, pressure sensor, microphone, motion sensor, and
pulse oximeter. The sensors can be seen in Figure 31.
87
Lab 5 SBIR
Figure 31. DFM system prototype major functional component diagram
Figure 32. Environmental sensor for the DFM system
88
Lab 5 SBIR
Figure 33. Occupancy detection sensors for the DFM system
4.5.1 DFM Virtual Instrument (VI) GUI
The DFM GUI is an interface used for the purpose of demonstrating and testing
the DFM system. It has the capability of turning on the components individually. It also
includes graphical components for interpreting the outputs for each sensor.
1.1. Turn on each component individually: This feature allows the user to turn on
or off any of the sensors and the key fob. There is a panel for each component
giving the capability of simulating the component, turning on the real
component, turning off the component, and force the component on. For the
simulated sensor, a set of random data points between a predefined range will be
generated to provide a simulated sensor.
1.2. Capable of preempting system: This feature allows the end user to preempt the
DFM system to prevent the alarm from going off. This feature is overridden
89
Lab 5 SBIR
when the temperature is in a safe state. There will be instances when someone
will leave the vehicle, leaving an occupant behind in the vehicle. One example of
this is when the driver wants to pump gas in the car.
1.3. Reset feature: This feature allows the end user to reset the DFM system. The
reset button when turned on will reinitialize the DFM system. If an occupant
and/or unsafe conditions are detected, the alarm will sound until the system is
reset.
1.4. Numeric Display: Numeric data fields are given for each component to provide
accurate readings in order determine the actual value returned from the sensor.
All numeric fields are read only. Every component has a numeric field display
including a numeric field for the displaying the danger level. All signal values
have a precision of three decimal places.
1.5. Light Emitting Diode (LED) Display: LED components are utilized in the
DFM interface to provide a visual of when the occupancy sensors: detect an
occupant; key fob is not detected; and when unsafe conditions are detected.
There will also be LEDs provided to show when the system and/or alarm is on.
1.6. Amplitude vs. Time Graph: A graphical chart provides a visual display of data
that otherwise would be presented in a text. A chart conveys ideas about the data
that would not be readily apparent if they were displayed as text. Charts are
provided for the microphone, CO2 sensor, motion sensor, pressure sensor, key
fob, and temperature sensor. Each chart can be selected by selecting the indicated
tab. Each chart is plotted by amplitude vs. time.
90
Lab 5 SBIR
4.5.2 Motion Sensor
The motion sensor utilized in the prototype features an ultrasonic motion sensor
included in an ultrasonic movement detector kit. The kit is assembled and soldered
together. The circuit uses a matched pair of 40 kHz transducer elements to detect
movement up to 22 feet away. An LED is included for movement indication. Sensitivity
is adjustable via control. To provide maximum stability, a Crystal locked circuit is used.
The motion detector will be utilized to indicate if a movement of one inch or more has
been detected which indicates occupancy.
2. CO2 Sensor: The prototype does not include a real CO2 sensor a feature, but does
provide the means for easily attaching a CO2 sensor for testing and demonstrating. A
CO2 sensor sub VI is incorporated into the main DFM VI so the end user can connect
the device to an open channel on the Data Acquisition System (DAQ). Furthermore,
the CO2 sensor can be simulated via the sensor panel on the DFM interface.
3. Temperature Sensor: For measuring linear temperature change, a linear thermister
will be utilized for the temperature sensor. The temperature sensor is a key feature in
order to detect harmful conditions in which the car can acquire extreme temperature
changes that can be harmful to living things. The thermistor sensor includes two
thermistor elements that when used with a resistor set will provide linear resistance
output over a specific temperature range
4. Pressure Sensor: The prototype does not include a real pressure sensor as a feature,
but does provide the means for easily attaching a pressure sensor for testing and
demonstrating purposes. A pressure sensor sub VI is written into the main DFM VI so
the end user can connect the device to an open channel on the DAQ. Furthermore, the
pressure sensor can be simulated via the sensor panel on the DFM interface.
91
Lab 5 SBIR
5. Pulse Oximeter: The pulse oximeter is a feature included to indicate life detected
within the compartment of a vehicle. The pulse oximeter is used to simulate a
heartbeat sensor. The pulse oximeter indirectly measures the oxygen saturation of a
patient's blood sample and any changes in blood volume. It has a small photodiode.
This is part of a clip that is attached to an individual’s finger. Using the ratio of
absorption of light, the oxy/deoxyhemoglobin ratio can be calculated. Normal ranges
are from 90 % to 100 %.
6. Microphone: The capability of detecting noise is a feature of the DFM system. A
computer microphone is used for noise detection. The microphone will check the
intensity of noise in the vehicle. In the event that the noise is above a predefined
decibel level, the signal from the microphone will indicate life.
7. Transmitter and Receiver (Key Fob): A radio frequency (RF) transmitter and
receiver are utilized in order to simulate a key fob and is a feature included in the
DFM system prototype. The effective range of the DFM system transmitter is10 feet.
The transmitter sends a signal to the car constantly; when the driver walks too far
away the DFM system will know the driver is gone.
8. Produce a Car Alarm Sound: An alarm is a feature provided in the DFM system
prototype. The car alarm will be represented by a car alarm wave file. The wave file
will be executed every time life or unsafe conditions has been determined.
9. Detecting Occupancy: For providing occupancy detection, an array of sensors is
utilized and a life detection algorithm is used. The life detection sensors include:
motion, pulse oximeter, microphone, CO2, and pressure. Each sensor has a preassigned value. By summing the values from all of the sensors, a total value of five or
92
Lab 5 SBIR
higher will indicate that life has been detected. The values assigned to each sensor
includes: a 4 for the pulse oximeter sensor, a 3 for the motion and CO2 sensor, 2 for
the pressure sensor, and 1 for the microphone. When life has been determined a signal
is sent from the Bluetooth transmitter to the Bluetooth receiver then generating an
alarm.
10. Detecting Unsafe Conditions: For detecting unsafe conditions, a temperature sensor
is utilized along with an unsafe condition algorithm. The temperature sensor will
constantly monitor the temperature with the compartment of the vehicle and look for
temperatures rising above 89 º F and temperatures below 31º F. The environment is
determined hazardous, if the temperature meets this requirement. After unsafe
conditions are determined, the transmitter will send a signal to the receiver
representing the key fob, and sounds an alarm simulated by a car alarm wave file.
4.6 Error Messages (Brandon)
All error messages generated by the DFM system are strictly related to
configuration and setup of the system. Since user input is restricted to a set of predefined
states in the DFM algorithm, it is unlikely that the user will encounter a system error on a
properly configured system. This section describes errors that the DFM system may
produce.
Error Cause
1. Log file not found or
present on the system.
Error Message
Corrective Action
“Error 1 occurred at Set File Position in log.vi->
Log file must be correctly
Pressure.vi->DFM.vi”
linked in the log VI.
93
Lab 5 SBIR
2. Alarm sound file not
The alarm sound file must
“Error 7 occurred at Sound File Read Open.vi->
found or present on
be correctly linked in the
Sound File Info (path).vi->Alarm.vi->DFM.vi,”
the system.
3. Microphone device
not found or
alarm VI.
“Error 4800 occurred at Sound Input
Microphone needs to be
Configure.vi ->Continuous Sound Input.vi”
connected to the computer
connected.
through the microphone
jack.
4. Too few sensors are
active to detect life.
5. Both the temperature
sensor and key fob
“Error 5000 Not enough sensors connected to
The sensor’s states must be
detect life.”
changed from disabled.
“Error 5001 Driver and temperature detection not
The key fob or the
possible.”
temperature sensor’s state
detection has been
needs to be changed from
shut off.
disabled.
6. The DAQ has been
disconnected or not
“Error 201003 occured at DAQmx Create
The DAQ must be plugged
Channel (AI-Voltage-Basic).vi”
into the computer through
present on the system.
the USB port.
Table 9. Error Messages
4.6.1 Errors by message

Error 1: This error means that a file is not present on the system that the DFM
system needs to run. This error is most likely to occur when a log file for a
particular sensor cannot be found. Either the path to the file is incorrect or the file
has been deleted.

Error 7: This error means that the sound file that the alarm system uses is not
present on the system. Either the path to the file is incorrect or the file has been
deleted.
94
Lab 5 SBIR

Error 4800: This error message means that the microphone cannot be found on the
system. If the computer needs an external microphone it should be connected. If
there is an internal microphone the drivers must be properly installed.

Error 5000: This error means that too many sensors are deactivated for the life
detection value to be 6 or higher. Therefore no combination of life detection
sensors will be able to detect an occupant.

Error 5001: This error means that both the temperature sensor and the key fob
device are disabled. The DFM will be unable to determine if the situation is
dangerous despite the life detection value.

Error 201003: This error means that the DAQ is not detected and therefore cannot
be used with the DFM system. The correct DAQ drivers must be installed and the
DAQ must be properly connected to the computer.
4.6.2 Errors by action number
1. Log file not found or present on the system. A log file must be created for one of
the sensors. The DFM system will not run unless a blank or non-blank log file for
each sensor is present. The system will halt and must be restarted.
2. Alarm sound file not found or present on the system. This error will only occur
when the alarm system tries to activate. The path to the sound file must be
correctly defined and the sound file must be present on the system. The system
will halt and must be restarted.
3. Microphone device not found or connected. The error will only occur when the
user select the real microphone. This error will not occur if an external
microphone is connected to the computer the DFM system is running on and the
95
Lab 5 SBIR
drivers for the microphone are correctly installed. The system will halt and must
be restarted.
4. Too few sensors are active to detect life. This error will occur if there are too few
sensors active for the life detection value to be 5 or greater. The system will halt
and must be restarted.
5. Both the temperature sensor and key fob detection has been shut off. If both
devices are disabled the system will be incapable to detecting a dangerous
situation. The system will halt and must be restarted.
6. The DAQ has been disconnected or not present on the system. A DAQ must be
present and connected to the computer. The DAQ configurations must be
corrected to reflect the DAQ connected to the computer. The system will halt and
must be restarted.
4.7 Troubleshooting (Brandon)
This section attempts to address common concerns a user may have regarding the
DFM system. The concerns user may have are written in query form. The solutions were
compiled by the DFM developers, and should give the user a better understanding of the
DFM system.

Vehicle Owner
o Problem: When I start my car a light comes on with the logo of the
Don't Forget Me system. It stays on until I take my keys out of the
ignition. Is this supposed to happen?
o Solution: The Don't Forget Me system is designed to bother the driver as
96
Lab 5 SBIR
seldom as possible. If the system light is alerting the driver it can only be
because the system is in need of servicing. Please consult your
automotive dealer to have your system repaired.
o Problem: What do I do once the alarm system is activated?
o Solution: To deactivate the alarm system, depress the reset switch at the
rear of the vehicle. If the emergency situation is not resolved the alarm is
be activated again in 15 seconds.
o Problem: I often drive with others who are perfectly capable of
leaving the car when the temperature becomes dangerous. Sometimes
I must leave adult passengers in the car so that I can perform a task
as they wait. Unfortunately, the alarm activates each time I leave the
car. Is there a way I can shut the system off so it does not bother me
about my passengers?
o Solution: The DFM system was designed to help those who are incapable
of leaving when the situation becomes dangerous. If the driver sincerely
believes the passenger is capable of leaving the vehicle on their own they
may use the “preemptive reset” feature. The preemptive reset prevents the
alarm from activating when life is detected and the driver's key fob is not
present, but will not work when the temperature reaches a dangerous level.
To activate the preemptive reset depress the reset switch before leaving
the vehicle.
o Problem: I have no need for the DFM system in my vehicle. Can I
leave the preemptive reset on permanently or completely disable the
97
Lab 5 SBIR
DFM system?
o Solution: No, the DFM system disables the preemptive reset when the
temperature reaches 90 degrees Fahrenheit or 30 degrees Fahrenheit, or
when the engine is turned on. Disabling the system should only be done
by your automotive dealer, and is strongly discouraged.
o Problem: How long will the DFM system alarm run if an emergency
is detected?
o Solution: The alarm will be activated from the moment an emergency is
detected until the reset switch is depressed. Even if the situation is no
longer harmful the alarm will continue until the reset is pressed.
o Problem: When the alarm is activated I press the reset switch to shut
it off. However, if the alarm comes back on 15 seconds later each
time. How do I fix this?
o Solution: If there is no one in the vehicle at the time the alarm activates,
the system needs to be serviced by your automotive dealer. If the alarm
was activated the first time due to an actual emergency, there was a 15
second period of time given to the driver to resolve the dangerous
situation. If the situation remains to be dangerous to the passenger(s) the
alarm will continue to activate within 15 seconds of the alarm being
pressed.
o Problem: I bring my pet with me when I drive. Do I have to worry
about the alarm system activating when I leave a pet in the vehicle?
o Solution: Yes, the DFM is not sophisticated enough to distinguish humans
98
Lab 5 SBIR
from other animals. There is a high likelihood that your pet could activate
the system’s alarm. To prevent the alarm from activating you may use the
preemptive reset feature, which will make no difference if the temperature
inside the vehicle becomes dangerous. The developers of the DFM system
strongly discourage leaving any person or animal unattended in a vehicle.
5 Lessons Learned
The role of each team member is important for building the project. The project
manager coordinated the meetings, assigned tasks to team members, and made sure tasks
were completed on time. The hardware specialist researched, designed and implemented
the hardware needed for the project. The software specialist selected software
development kit to be used, designed and wrote the interface. Document specialist
compiled the completed documents in a legible format.
The technical issues encountered were hardware failures. The first hardware
failure was the pulse oximeter to work properly. Pulse oximter was purchased through
the internet without any documentation included. The team made trial and error to make
the pulse oximeter works properly. The second hardware failure was the motion sensor.
The motion sensor suddenly stopped working in the middle of prototyping. The
components in the circuit board were replaced to fix the issue.
The software development issue was the development of the DFM system
algorithm. LabView was the chosen software for the team’s project because of the
utilization of various sensors. The team had a hard time learning and implementing the
software’s capabilities.
99
Lab 5 SBIR
The completion of the prototype was two months ahead than the 410 estimation.
DFM Inc. had a reduction in salary due to a team member’s personnel issues. The budget
for 411 was accurate to the 410 estimation except for couple of sensors that were not
implemented due to knowledge level and time constraints.
Since the presentation requires Microsoft PowerPoint, certain knowledge is
required for using the Microsoft PowerPoint. One needs a degree in English to meet the
requirements in the workforce. One also needs an extensive knowledge in APA style in
writing.
6 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
Part #
Company
Qty Price Ea Total
Sensor, Ultrasonic, 40Khz, Tran
136654 Jameco.com
2
$7.95
$15.90
Sensor, Pressure, 0-1.45 PSI
218827 Jameco.com
2
$8.99
$19.98
Kit, Infrared Tran and Rec
177092 Jameco.com
2
$24.95
$49.90
Linear Thermistor Air Temperature
OL-706
Omega.com
1
$61.00
$68.00
for_Pulse_Monitor_1034.html
P-703A
FitnessEquipment
2
$19.99
$39.98
USB-6008 Kit (LabVIEW and DAQ)
77932022
NI.com
2
$159.00
$331.62
Pulse Oximeter
http://www.fitness-equipment.com/acatalog/
Online_Catalog_Pulse_Monitor__Ear_Clip_
100
Lab 5 SBIR
Software Purchase (list all items required for purchase):
Part Description
Part #
Company
FRAPS - Real-time video render
software
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
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.
2
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.
101