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