Lab 1 – DFM Product Description, David Ballentine 13
Lab 1 – DFM Product Description
David Ballentine
CS411
Janet Brunelle
February 3, 2007
Table of COntents:
1 INTRODUCTION 3
2 DFM PRODUCT DESCRIPTION 4
2.1 Key Product Features and Capabilities 5
2.2 Major Components (Hardware/Software) 5
2.3 Target market/Customer Base 7
3 DFM PRODUCT PROTOTYPE DESCRIPTION 8
3.1 Prototype Functional Objectives 8
3.2 Prototype Architecture(Hardware/Software) 9
3.3 Innovative features (of prototype) 11
3.4 Challenges and Risks 11
4 PROTOTYPE DEMONSTRATION DESCRIPTION 12
GLOSSARY 13
WORKS CITED 14
LIST OF FIGURES:
Figure 1. Kids and Cars Children Fatality Diagram 4
Figure 2. DFM Major Functional Component Diagram. 6
Figure 3. DFM Prototype Major Functional component Diagram 10
1 INTRODUCTION
In 2004, a baby girl died after being left alone inside a vehicle for more then three hours. (Baby Left in Hot Van Dies, 2004). More recently in 2007, in Tennessee, a baby boy also died after being left a vehicle. (Baby Left in Car Dies from Heat, 2007). In this case, the father was charged with negligent homicide. Every year, children are accidentally left alone in vehicles. This happens for a great number of reasons including a change in the parent’s schedule, a quick stop turning into a long ordeal, or even while taking care of another emergency. Unfortunately, deaths occur when conditions inside the vehicle become too hostile. The vehicle becomes a prison as the child, being too young, is unable to escape.
The most common factor is heat. Body temperatures above 104°F are life threatening, while at 106°F brain death begins. A temperature of 113°F is almost certain death. Inside a standard vehicle on a moderate spring day of 85°F, the inside of the car will reach 100°F in just seven to ten minutes, and 100°F in just half an hour. If the outside temperature is around 100°F, than the internal temperature will reach 140°F in just under 15 minutes (Excessive Heat Events Guidebook, 2006). A vehicle has the potential to become inhospitable in a very short amount of time, thus leaving any children left inside to a torturous death.
Figure 1 indicates that the two most prominent fatalities involving children, not including crash victims, are the child being back over by the vehicle, and the child being left inside and dieing from the hot weather. The first problem, the child being run over, is currently being addressed by the vehicle industry by attaching rear view cameras to the back of vehicle. This document addresses how the second problem, the child being left in the vehicle, can now be addressed with the Don’t Forget Me (DFM).
Figure 1. Kids and Cars Children Fatality Diagram (2007)
2 DFM PRODUCT DESCRIPTION
The DFM is a life saving tool utilizing sensor technology designed to prevent a child from being left behind in a vehicle. The system will be implemented into vehicles at the time of their manufacture. In a vehicle installed with a DFM, the system will be active at any time the car is parked, including when the car itself is off. Utilizing sensors such as a pressure sensor and a motion sensor, as well as a few others, the system will calculate the probability of a child being in the seat. It will also calculate how far the driver is from the vehicle by tracking the vehicle key.
When the DFM concludes that there is a child in the seat, and if the driver is more then ten feet away from the vehicle, the vehicle’s alarm will sound. There is then the option to temporarily disable the alarm. A switch on the child’s seat will turn off the alarm. The driver or a child old enough can activate this switch. This will cause the system to enter standby mode. It will continue to monitor the child, 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 child being removed from the vehicle.
2.1 Key Product Features and Capabilities
The key features of the DFM include the design of using a broad range of sensor technology, as well as building the system into the vehicle directly. Other similar products are incorporated instead into a specialized child car seat. This approach has the inherent flaw in that it has to be purchased specifically by the customer. A typical parent will not admit to any possibility of this happening and thus will not buy the specialized car seat. Since the DFM is incorporated into the vehicle during manufacture, it will simply be an included protection much like standard air bags. Its operation will be transparent to the user until there is a problem.
Since similar products build the system into a car seat, certain assumptions about the baby actually being in the seat are made. The DFM cannot make these assumptions and thus must use a broad arrangement of sensor technology to determine if there is a child in the vehicle, the environmental condition inside the vehicle, and what response to take. These two features make it a unique and superior system for saving lives.
2.2 Major Components (Hardware/Software)
Most of the components used by the DFM are sensors. There are also the transmitter device and the car alarm. Figure 2 shows the setup of the components.
Figure 2. DFM Major Functional Component Diagram (2008).
Every sensor needed for the DFM serves a specific purpose. The pressure sensor, accelerometer sensor, and motion sensor serve to determine if there is a child in the seat. All three of the sensors are needed since an individual sensor could be fooled. A backpack, for example, could trigger the pressure sensor. The three work on an algorithm designed to make a highly accurate prediction on if there is a child in the seat. The temperature sensor determines the condition inside the vehicle. Temperatures above or below a certain point are considered dangerous. The accelerometer sensor will also be used to monitor the child, and thus has a duel purpose.
The transmitter device will be inside of the vehicle’s key. The remote detector will pick this up. When the signal degrades to a certain point, this will mean there is more then a ten-foot distance between the transmitter and detector. At this point, if there is a child inside the vehicle, the car alarm will sound. The reset switch to temporarily disable the alarm is located on the seat the child is on. Once flipped the system will switch to standby mode until the conditions become too harsh.
Although the DFM utilizes all of these components, none are included with the DFM system. The software algorithm, as well as a list of needed, and compatible devices will be included however. The car manufacture will be responsible for the actual integration of the devices in each separate make of vehicle. The reason for this arrangement, is that every car model is different. It would be impossible to provide specific sensors that would satisfy the requirements for every model. Also each manufacturer has its specific way of doing things, and wiring components. The DFM has to be seamlessly integrated and thus why it is up to the manufacturers.
The DFM software will be able to analyze the sensors hooked up to it, and make the actual predictions. This is the core of the DFM and what is actually being marketed. The algorithm must be precise enough to not through false alarms, yet never fail to alarm if there is a real threat.
2.3 Target market/Customer Base
The target customer of the DFM is car manufacturers. The system is to be installed directly into the vehicle during the vehicle’s manufacture. The manufacturer will purchase the DFM software for a vehicle model, and a license to use it for every vehicle it is installed into.
The secondary costumer is the end user. While the DFM will not be marketed directly to the end user, this user must still be considered in the creation of the DFM product. If something goes wrong with the system, this end user will be the one to complain to the manufacturer. The DFM must work transparently to the end user until a situation requiring the device to sound the alarm.
3 DFM PRODUCT PROTOTYPE DESCRIPTION
The prototype of the DFM will encompass almost everything that will be on the final product, except on a smaller scale. The prototype will also have a major Graphical User Interface (GUI) to show exactly what is going on at the sensor level. The user will also be able to change certain variables, for example the temperature, and witness the results.
3.1 Prototype Functional Objectives
The first objective of this prototype is to demonstrate that the sensors will work as planned. These sensors have never before been put into this arrangement to work in this situation. The foundation of the theory is sound, but certain complications only arise when tested. This prototype will serve as that test bed for these sensors. This prototype will also prove that the idea is sound and production should go forth.
The second objective of this prototype is to provide a tool to work out some of the specific algorithms. These algorithms must be very accurate, and there is no way to simulate some of the situations without an actual live experiment. This prototype will provide a way to scrutinize these algorithms until they are as accurate as possible.
The third objective is to root out any major design flaws. It may be that another sensor must be placed into the scheme for the system to work, or the transmitter for key is not strong enough to broadcast over ten feet. This prototype will determine these factors among others. The final product will be greatly influenced by what works well, and what does not during the prototype.
The fourth and final objective of this prototype is a marketing basis. This prototype can be used to sell the DFM to a manufacturer. Without it, the manufacture will have no real world example of how the system is supposed to work, and how it should be implemented into their vehicles.
3.2 Prototype Architecture (Hardware/Software)
The prototype will utilize the same types of sensors and setup as the final version. These will be simpler counterparts however compared to the ones that will be used in the final product. Figure 3 shows the prototype setup. It is essentially identical to the final version. This is necessary because the software is the key to the DFM product, and must be tested with all the hardware it will use.
Figure 3. DFM Prototype Major Functional Component Diagram (2008).
The software in the prototype includes the software with the algorithms that will be in the final product, as well as a GUI display. The GUI display will show the status of the current sensors. All of the sensors will be in working condition, however for testing and demonstration purposes, these values can also be overridden. An example would be changing the temperature inside the car, and watching the results of this action. This part of the prototype will be using a program called LabVIEW to process both the sensor, and simulated datasets.
3.3 Innovative features (of prototype)
This prototype demonstrates that the DFM product is feasible, and how the system works. As mentioned in this document, the DFM employs a unique arrangement of sensors to work for a specific goal. The prototype will show that this arrangement is the best for what is trying to be accomplished.
The GUI of the prototype will also demonstrate exactly what is going on at a low end level. The exact state of the program can be witnessed in real time. The user will be able to manipulate the program and simulate any and all potential situations. The strength of designing the prototype in this way, is real-time assessment of whether the software algorithms are working correctly or not.
3.4 Challenges and Risks
The major challenge of this prototype is to get the algorithms to work exactly as planned. There is little room for error when at the final product, since human life is on the line. The system must show that the sensors work and that this is a viable solution. Another major challenge is to acquire the needed sensors in the time and money allotted.
A major risk of this prototype is to not show enough of the end product. If a close enough example of the DFM is not shown, no one will be convinced that the DFM can work. In this case the prototype will be a failure. There is also the risk of showing too much and thus making every one expect more from the end product. A balance between the two risks must be met for a successful prototype.
4 PROTOTYPE DEMONSTRATION DESCRIPTION
The prototype demonstration will take place at the beginning of May, 2008 in the ODU Computer Science conference room. In a mach-up scenario, each of the sensors will be demonstrated in both its functionality, and its purpose in the overall design. After this, several simulations will be made overriding the actual sensors to show results under different datasets. The floor will also be open for any audience members to recommend any input value into the program to observe what will happen.
GLOSSARY
DFM: Don’t Forget Me
Accelerometer Sensor: Used to detect vibrations. In this application it is used to detect a heartbeat.
GUI: Graphical User Interface. A display on a computer that uses graphics to display content and can allow user manipulation.
LabVIEW: A graphical programming tool allowing for the display and acquisition of data from a great deal of devices including external hardware.
WORKS CITED